AW: [xacml] New issue: new attribute ids for xml multiple decisions

["Jan Herrmann" <herrmanj@in.tum.de>]

Hi Paul,

I like your proposal but I am wondering why you are not using the
resource-id attribute directly instead of adding the new
authorized-resource-id attribute. Let me explain:

According to your proposal a multiple decision request and one of derived
decision requests will look like this:

multiple decision request: 
- resource-selector = xpath that selects a set of nodes
- scope = "XPath-expression"
- resource-id = empty? or not present?
What is the value of resource-id in a multiple decision request?

derived individual decision request:
authorized-resource-id = xpath to exactly one node (in the set as specified
by resource-selector and the scope value).
- resource-id ??

It seems to me that we could also say that in a multiple decision request
the value of the resource-id attribute must be empty (or even not present
what seems to be allowed following the schema for <Request>). Further we
could say that in the derived individual request the resource-id will have a
value equal to one of the individual resource (as specified by
resource-selector and the scope value). Thus resource-id in the individual
decision request will equal to what your proposed authorized-resource-id
will do.

This solution will fulfil the problem 2 you pointed out (i.e. overloaded
resource-id meaning) and in case we exclude the resource-id value in the
multiple decision request than issue 1 will also be addressed.
The advantage, reuse the existing resource-id attribute instead of
introducing a very similar new authorized-resource-id. BTW why did you put
authorized in the name?


Best regards
Jan


> -----Ursprüngliche Nachricht-----
> Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Gesendet: Donnerstag, 19. November 2009 23:10
> An: XACML TC
> Betreff: [xacml] New issue: new attribute ids for xml multiple decisions
> 
> The cd-1 Multiple profile, lines 109-111, specifies that the resource-id
> attribute in a multiple decision request shall be replaced with a
> (possibly) different value when creating individual requests.  The new
> value is the one that would be returned (if IncludeInResult=true) in the
> result.
> 
> There are a couple of problems with this.  First, it breaks an implicit
> contract that prohibits the context handler from changing attribute
> values (it can provide more values, but should never change or remove
> values from the original request context).  Second, it overloads
> resource-id with a new meaning that is different from its initial
> purpose as a primary identifier of a resource.  When used in a multiple
> decision request for XML content, resource-id now means something like
> "resource selector" in the Request, but reverts to its former meaning as
> "primary identifier" in the Response.
> 
> I propose that the resource-id attribute should only be used as a
> persistent primary identifier for a singleton resource, and that two new
> attributes be defined: one for requesting decisions on multiple nodes of
> XML content, and another for identifying those nodes in a XACML
> response.  The proposed AttributeIds are:
> 
> urn:oasis:names:tc:xacml:3.0:profile:multiple:xml:resource-selector
> urn:oasis:names:tc:xacml:3.0:profile:multiple:xml:authorized-resource-id
> 
> Sections 2.2.2 and 2.2.3 of the Multiple profile should be rewritten as
> follows:
> 
> =====================
> 2.2.2 Original request context
> 
> The original XACML request context <Attributes> element in the resource
> category SHALL contain a <Content> element and an attribute with and
> AttributeId of
> "urn:oasis:names:tc:xacml:3.0:profile:multiple:resource-selector" and a
> DataType of "urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression",
> such that the <AttributeValue> of the "resource-selector" attribute is
> an XPath expression that evaluates to a nodeset that represents multiple
> nodes in the resource category <Content> element. The <Attributes>
> element with the resource category SHALL contain a "scope" attribute
> with a value of "XPath-expression".
> 
> 2.2.3 Semantics
> 
> Such a request context SHALL be interpreted as a request for
> authorization decisions on multiple nodes in the nodeset represented by
> the <AttributeValue> of the "resource-selector" attribute. Each such
> node SHALL represent an Individual Resource.
> 
> Each Individual Decision Request SHALL be identical to the original
> request context with two exceptions: the "scope" attribute SHALL NOT be
> present and an additional attribute with AttributeId of
> "urn:oasis:names:tc:xacml:3.0:profile:multiple:authorized-resource-id"
> SHALL be present.  The DataType of this attribute shall be
> "urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression", and the value
> SHALL be an XPath expression that evaluates to a single node in the
> <Content> element. The IncludeInResult XML attribute SHALL be "true".
> The content XML node selected by this Attribute SHALL be the Individual
> Resource. If the "resource-selector" attribute in the original request
> context contained an Issuer, the "authorized-resource-id" attribute in
> the Individual Resource Request SHALL contain the same Issuer.
> ==============================
> 
> See these emails for previous comments on this issue:
> 
> http://lists.oasis-open.org/archives/xacml/200910/msg00036.html
> http://lists.oasis-open.org/archives/xacml/200910/msg00052.html
> http://lists.oasis-open.org/archives/xacml/200911/msg00025.html
> 
> Regards,
> --Paul
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php