RE: [xacml] New profile drafts: Hierarchical Resources and Multiple Resources

[Tim Moses <tim.moses@entrust.com>]

Hi Anne - Here are some comments on the "hierarchical resources" profile.  I
confess I found this one harder to grapple with than the "multiple
resources" one.  It is unavoidably complicated and the reader might welcome
a bit more "hand holding".  I think it would help if the Introductory
section listed all the considerations that had led to this design.  I
believe, at present, it only lists some of them.  Is that true?  Anyway,
something to think about.  All the best.  Tim.

Line numbers from PDF version

General

I would find it helpful if Section 1 laid out what problems surround writing
policies and requesting access in the case of hierarchical resources.  This
section does suggest some of them.  But, is the discussion complete?  For
instance, emphasize that we are interested in two types of hierarchy: xml
documents (which cannot be forests - right?) and non-xml resources.  For the
former, the PEP must present the XML instance, for the latter, it must
present the set of identifiers for the parent(s) and ancestors.  Could we
explain why this is necessary?  After all, the URL representation of the
resource-id explicitly describes the hierarchy in this case, provided we are
not dealing with a forest and nodes have only one normative representation.
In the XML case, the node to which access is requested may be "embedded in"
the resource-contents, rather than being the entire contents.

Perhaps, we should mention that there are circumstances in which a
particular resource has different normative representations (can we supply
an example?).

Another problem we have to deal with is that applicable policies may be
targeted at nodes that are superior or inferior to the node identified by
the resource-id.

Trivial

70 - Unbold "authorization" and embolden "request".  Only "decision request"
is in the glossary.
73 - I felt the layering was better described the other way around (i.e.
hierarchy on top of multiple).  I found this profile easier to approach once
I had read the "multiple resources" one.  In fact, I wouldn't mind seeing
some language that encourages the reader to become familiar with the other
profile before tackling this one.
168 - Change "Distributed" to "Domain".
175 - Can you explain what "resolved" means in this context?
177 - Do we have to say this, since we say in line 176 that all paths are
absolute?
200 - Unbold "attributes".  I think this is talking about XML attributes,
not XACML attributes.  No?
203 - We should say what is the context node for these XPath expressions.  I
expect, the context node should be the one and only child of the
<ResourceContent> element.
215 - Put a full-stop at the end of the sentence.
225 - Should document-id be the name of the element that is the one and only
child of the <ResourceContent> element?  If it contains a namespace
declaration, should the document-id be the name-space-qualified element
name?
Section 3.2 - Why not state that there is no <ResourceContent> element in
this case?
236 - Unbold "attributes".  I think this is talking about XML attributes,
not XACML attributes.  No?
238 - Change "AttributeId" to "AttributeId of".
243 - How about reminding the reader why there may be more than one parent?
263 - Change "values" to "order of the values".
282 - "Unless the representation recommended in Section 3.2 is used".  Used
by whom?  The PEP, in forming the request?  But, because we use the URL
representation, the representations DO indicate the path, do they not?
295 - This is described in Section 7.2.1 of the core spec..  Is it helpful
to repeat it here?
301 - Change "only to non" to "only in non".
305 - Is it not the case that URI functions are the ONLY ones that can be
used with resource identifiers in this case?  In which case, the MAY should
be a MUST. No?
Section 5.1 - This data-type is defined in the core spec..  Is it helpful to
redefine it here?
 

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] 
Sent: Tuesday, August 03, 2004 2:15 PM
To: XACML TC
Subject: [xacml] New profile drafts: Hierarchical Resources and Multiple
Resources


I have uploaded new working drafts of two related profiles:

1. XACML Profile for Hierarchical Resources, Working Draft 05, 29
   July 2004

   PDF:
http://www.oasis-open.org/committees/download.php/8431/oasis-xacml-profile-h
ierarchical-resources-wd-05.pdf
   OpenOffice:
http://www.oasis-open.org/committees/download.php/8432/oasis-xacml-profile-h
ierarchical-resources-wd-05.sxw

   Includes the following changes:
   o editorial corrections for greater clarity,
   o inclusion of the new "document-id" AttributeId in the list
     of new AttributeId values,
   o use of the name "...:regexp-uri-match" as the name of the
     URI matching function (defined in core, not here),
   o added URIs to identify each implementable option in the
     profile.

   No new non-optional functionality has been included.

2. XACML Profile for Requests for Multiple Resources, Working
   Draft 03, 3 August 2004 (PDF and OpenOffice formats)

   PDF:
http://www.oasis-open.org/committees/download.php/8433/oasis-xacml-profile-m
ultiple-resources-wd-03.pdf
   OpenOffice:
http://www.oasis-open.org/committees/download.php/8435/oasis-xacml-profile-m
ultiple-resources-wd-03.sxw

   Includes the following changes:
   o "Contributors" moved to "Acknowledgments" due to lack of
     room on front page,
   o Bill and Simon affiliation changed to GlueCode Software,
   o added Ron Jacobson to Acknowledgments,
   o added mechanism for requesting a single response for access
     to an entire hierarchy,
   o added new "scope" attribute values for the XPath-expression
     mechanism and for the "entire hierarchy" mechanism, and
     editorial changes for greater clarity.

   No new non-optional functionality has been included

Comments invited and welcomed.

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


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
hp.