MHonArc v2.5.0b2 -->
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 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?