[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] New profile drafts: Hierarchical Resources and Multiple Resources
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]