OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] New profile drafts: Hierarchical Resources and Multip leResources


Tim,

Thanks a million for these comments.  Here is how I addressed
them.  The line 225 comment about "document-id" is probably the
one most needing more discussion.

On 18 August, Tim Moses writes: RE: [xacml] New profile drafts: Hierarchical Resources and Multip	le 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.

I agree the Intro did not sufficiently introduce the concepts.  I
amplified and rewrote the Section 1 Introduction with more
explanatory and motivating material.

It is indeed complicated.  I wish we had a gifted tech writer to
tackle this!  And someone with more XML expertise to help with
the XML resource sections.

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

I think I have now covered these topics in the Introduction, at
least better than before.

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

Done.

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

Covered now to some extent in the Introduction.

 > Trivial
 > 
 > 70 - Unbold "authorization" and embolden "request".  Only "decision request"
 > is in the glossary.
Done
 > 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.
Agreed.  Hierarchy should be layered on Multiple (although
Hierarchy can also be layered directly on the Core).  I changed
the wording and added a recommendation to become familiar with
Multiple Resources.
 > 168 - Change "Distributed" to "Domain".
Done.
 > 175 - Can you explain what "resolved" means in this context?
I changed to "The <pathname> SHALL contain no soft links."
 > 177 - Do we have to say this, since we say in line 176 that all paths are
 > absolute?
Agreed.  I removed it.
 > 200 - Unbold "attributes".  I think this is talking about XML attributes,
 > not XACML attributes.  No?
Correct.  I unbolded, changed to "XML attributes", and added note
to definition of "Attribute" saying this term could also refer to
an XML syntactic attribute, in which case it will be qualified as "XML attribute".
 > 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.

I changed the description of resource-id, resource-parent, and
resource-ancestor to be consistent.  The description is now:

An <Attribute> element  with an AttributeId of
"urn:oasis::names:tc:xacml:2.0:resource:[resource-id /
resource-parent / resource-ancestor]" and a
DataType of
"urn:oasis:names:tc:xacml:2.0:data-type:xpath-expression". 
The <AttributeValue> of this <Attribute> SHALL be an XPath
expression; the context node for this XPath expression SHALL be
the one and only child of the <ResourceContent> element.  This
XPath expression SHALL evaluate to a nodeset containing the
single node in the <ResourceContent> element that is the
<node to which access is requested / immediate parent of the node
represented in the resource-id attribute / respective parent of
the node represented in the resource-id attribute>.  This
<Attribute> MAY specify an Issuer.

 > 215 - Put a full-stop at the end of the sentence.
Done
 > 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?

The current wording says:

  The <AttributeValue> of this <Attribute> SHALL be a URI that
  identifies the XML document of which the requested resource is a
  part, and of which a copy is present in the <ResourceContent>
  element.

Do we need to expand on this?  As worded, I don't think it would
contain a namespace declaration, since it is a URI, right?

If I am wrong, can you suggest alternative wording here?

 > Section 3.2 - Why not state that there is no <ResourceContent> element in
 > this case?
Done.
 > 236 - Unbold "attributes".  I think this is talking about XML attributes,
 > not XACML attributes.  No?
Done.  Now explicitly says "XML attributes".
 > 238 - Change "AttributeId" to "AttributeId of".
Done
 > 243 - How about reminding the reader why there may be more
 > than one parent?
Done.
 > 263 - Change "values" to "order of the values".
Done
 > 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?
Used by the PEP.  Use of the URL representation is optional (per
Daniel).
 > 295 - This is described in Section 7.2.1 of the core spec..  Is it helpful
 > to repeat it here?
Good point.  I removed it.
 > 301 - Change "only to non" to "only in non".
I changed to "Policies applying only to nodes in non-XML
resources".  I changed the previous heading to "Policies applying
only to nodes in XML documents."
 > 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?
If we are discussing only the standard functions, then yes.  But
there might be other extension functions available.  This entire
section is non-normative, and is intended just to inform readers
about facilities already available in core XACML that can be
applied to hierarchical resources.  I don't feel strongly on
this, though.
 > Section 5.1 - This data-type is defined in the core spec..  Is it helpful to
 > redefine it here?
I removed it.  At the time the profile was originally written, it
had not been decided whether it should be in the core or in this
Profile.  It appears to be not entirely clear even now :-)

Thanks again.  It is so important to have another set of eyes
besides the editor doing this detailed reading.

Anne

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]