Issues for the next delegation draft

[Erik Rissanen <mirty@sics.se>]

All,

I have started working on the next draft (the upcoming draft 08) and I
would like some input on some specific issues.

My focus on the next draft is to make it consistent and easier to
understand. I am going to clean up typos and to improve the text where I
feel it is hard to understand or ambigious. I am not planning to
introduce any new features in this draft.

Below is a list of the main changes I am planning to make and issues
that I would like to have input on. Some of these are taken from the
input I have previously received on the list (thanks to Tim, Anne, Hal,
Ron, and others).

* Should the new elements of the target/context be called "Issuer" or
"Delegate"? This had been discussed on the list, and it seems like there
is more agreement on "Issuer". Please let me know what I should use. If
I get no input, I will change it to "Issuer". I also assume that the
elements should have the same names in both the context and the target.

* I will leave the name of the "PolicyIssuer" element as it is.

* I will change "Administration" to "Administrative" where appropriate,
as previously discussed on the list.

* When I improve the text, I will use the term "pending policy" if there
is a need for it. (I will see how this goes once I get into the details
of the text.)

* I will add text describing that the context handler can provide issuer
attributes in addition to the attributes in the PolicyIssuer element. I
will also write that the attributes must be verified (by implementation
specific means). The attributes in the PolicyIssuer element also need to
be verified before the Policy is allowed into the PDP.

* I would like to have some feedback on the format of the trusted
issuer. Unless I get feedback, I will leave it as it is (except I will
change "delegate" to "issuer"). Also, should we allow a missing
PolicyIssuer? I think we should since it provides backwards
compatibility. The current draft (07) allows a missing PolicyIssuer and
defines the semantics for that, so I am not going to change that unless
I get feedback on this issue.

* What should we call the "LaterDelegate"? For now I will change it to
just "LaterIssuer", unless I get concensus on a better name.

* I am not going to get into the details of the LaterDelegate in this
draft. There are some open issues for this element and how it can be
referenced in a condition, but I am saving them for a later draft since
I am focusing on cleanups for this draft.

* What is the logic behind the bold formatting? I have noticed that the
previous XACML documents use a bold type for certain words. I assume
these are the words that are definined in the terminonology. Am I
correct? I want to make the use of the bold type consistent for this draft.

* Currently the non-normative plain language description uses the term
"reduction" while section 5.2.4. in the normative text use the term
"value authorization" for the same thing. Which is more preferable?
"Reduction" is nicer in the sense that it does not have any double
meaning in this context, while "value authorization" is more
descriptive. I am not sure what I think about this myself yet.

* Should we forbid the use of "Deny" results, or just say that support
for them is not required by an implementation? Currently the draft is
inconsistent on this issue. Just forbidding them might be simpler, but I
can imagine that in some special applications deny results could be
useful, so we might want to allow them.

Please let me know on the list or during the meetings what you think
about these issues. I will do the next draft next week to allow some
time for you to think.

Best regards, Erik