Re: [xacml] SP01: 18c comments. Forwarded message from Seth Proctor.

[Anne Anderson <Anne.Anderson@Sun.com>]

[Apologies to Seth and to the list: some of Seth's comments were
intended for me, and were not for the list as a whole (at least
not yet).  -Anne]

 >  - In section 5, when the <Function> tag is explained in Apply, it
 >      should have a pointer to the higher-order bag section so people
 >      understand what it's there for

To be more specifically, in Section 5.21 Element <Apply>,
explanation of <Function> [Optional], p. 54, line 2260, following
"The name of a function that is applied to the elements of a
bag.", append: "See Section A.13.11 Higher-order bag functions."

 >  - 10.3.6 (Identifiers) doesn't list the type of any these attributes,
 >      nor does it give the required uses for them that it says
 >      implementors must follow. I realize this is transparent to a lot of
 >      the code, and only one of these is required to support, but it would
 >      still be helpful to know what type they're supposed to be (if there
 >      is a certain expected type). Later in the spec they're explained in
 >      a little more detail, but not enough to make the strong language in
 >      this section about correct implemention make sense.

I don't think there is a specified type for these.  You specify
the type using the XML Datatype="" attribute.  One user might
specify key-info, for example, using a SubjectKeyInfo from PKIX,
while another might use a ds:KeyInfo structure.

 >  - A.6 (Element <AttributeValue>) says that an AttributeValue's type is
 >      implied by the function using it, but that's changed now to state
 >      the type explicitly (same for next 2 sections)...actually, this
 >      change is missing in most of the section A examples.

Agreed.

 >  - A.11 (Matching elements) says that the AD/AS used in a Target match
 >      must return a bag, and then has some other language that borders on
 >      describing an API. This is the section we talked about. I think it
 >      should be made clear that if a function expects a single String (eg),
 >      then getting a bag is an error. Also, this section (and the section
 >      later describing bags) should clarify that _any_ type is allowed in
 >      a bag, not just those defined as base types in the spec. If you'd
 >      like, I can work on alternate language.

Yes, please propose alternate language.

 >  - B.9 (Status codes) is still missing some of the codes that we
 >      discussed (like problems choosing the root policy). Maybe a few more
 >      could be added. Maybe I should writeup a few other codes, and include
 >      some proposal for the format of the values to accompany various
 >      Status codes?

Yes, please write up the proposed new status codes and the format
for their values.  To all: I think we MUST specify the format for
the information provided with every status code we define.
Otherwise, we will have non-interoperable formats being used.

 >  - D (Acknowledgments) ... this is a small issue, but since the list of
 >      voting memebers is basically also the contributer list, shouldn't
 >      this section name people who weren't on the TC but helped shape the
 >      standard? This is the way other specs look.

We put everyone who has been a member of the TC during the period
of the development of this spec into "Contributors".  The
Acknowledgments section will include only those who were voting
members as of the date when we vote to make this document a
"Committee Spec".

 >  - Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of
 >      just AD? Before it made sense, since all ADs were the same, but I
 >      would think that since there's now a special AD for Subjects, that's
 >      what you would want to extend.

Simon?

 >  - There is still no discussion anywhere about treating the Request as a
 >      notional doc and going outside the PDP to get attribute values. The
 >      same text is still throughout the spec suggesting just the opposite,
 >      and the picture at the beginning looks the same. I know you're thinking
 >      about how to change this, but if this is really supposed to be supported,
 >      then the spec _must_ change dramatically to make this clear. One or
 >      two paragraphs added somewhere will not cut it.

Some of the "one or two paragraphs added somewhere" are in a new
section proposed in PH09: "7.4.2 Attributes" that includes
subsections on Attribute Retrieval and Missing Attributes.  The
rest is already in the document in Section 7.7 Use profile for
XACML request.

If more text is needed to make these sections clear, please
propose it.

I'll try to make a pass through the doc for places where the doc
is not consistent with 7.4.2 or 7.7, which are normative.  I
started this in e-mail titled "Request Context and presence of
Attributes" and sent 07 Oct 2002 15:48:09 -0400 (EDT), but that
needs to be brought up to date with the current document revision.

 >  - Related to that, there needs to be some clear examples of how to use an
 >      AD/AS to make this happen. I don't think that AS's should be used for
 >      this functionality (just because it's too hard to support), but that's
 >      a separate issue.

Isn't that an implementation issue?  The spec should just specify
the desired behavior, not how it is achieved.

 >  - There is still no text about how to do resolution in an Apply, and how this
 >      can be short-circuited, etc. Are you working on this change? The
 >      current spec doesn't make it clear that you should be able to do this,
 >      so I think this needs to be added in clear examples & specification,
 >      otherwise not all implementors will get this right.

I think this is in 7.7 Use profile for XACML request.  If not,
could you be more specific about what is needed?

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692