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

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

------- start of forwarded message -------
From: Seth Proctor <seth.proctor@sun.com>
To: anne.anderson@sun.com
Subject: 18c comments
Date: Wed, 16 Oct 2002 11:10:16 -0400


Ok. Here is what I came up with (there's probably other smaller stuff too, 
but I was focusing more on the big picture). I suspect you've already caught
a lot of these, but just in case...

By Section:

 - 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is
     computed before arriving at the PDP. I know you're working on new
     language, so that may just not have been added yet.

 - 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

 - 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.

 - 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.

 - 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.

 - 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?

 - 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.


General:

 - 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.

 - 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.

 - 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.

 - There should probably be some language added to discuss how Policy[Set] Ids
     should be treated. At the very least, and example or some hints about
     typical use would make things better, since right now this is entirely
     up to the implementor, and as such is guarenteed to be a point where
     interoperability of policies fails.

 - 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.


seth

------- end of forwarded message -------

-- 
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