Re: A Problem with the "delegated:" Prefix

[Steven Legg <steven.legg@enitiatives.com.au>]

If a change to the XML Schema is entertained, then it would be easier
all round to just get rid of the category prefixing altogether and
instead label each policy as either an access policy or an administrative
policy. When assessing an access request the PDP would ignore any policy
labelled as an administrative policy. When assessing an administrative
request the PDP would ignore any policy that is *not* labelled as an
administrative policy. The procedure for generating an administrative
request would be much the same as it currently is except that steps
1.b. and 1.d. are replaced with "An <Attributes> element with any other
Category maps to an identical <Attributes> element".

Labelling the policies solves a number of problems. The problem that
prefixing an arbitrary category URI does not necessarily result in a
valid URI goes away. The need to prefix XPathCategory values goes away.
The problem of what to do with access requests that contain categories
that are already prefixed goes away. Also, the implementation of
delegation becomes easier for PDPs, PAPs and policy writers, and allows
more efficient processing by PDPs.

Regards,
Steven

On 24/05/2012 10:00 AM, Steven Legg wrote:
> On 21/05/2012 2:11 PM, Steven Legg wrote:
> > Step 1.d. in Section 4.5 of Committee Specification 1 of the XACML v3.0
> > Administration and Delegation Profile Version 1.0 simply assumes that
> > concatenating "urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:" with
> > the Category URI results in a valid URI. While this is true when the Category
> > URI is a URN, it is not necessarily the case in general for any arbitrary URI
> > because there are certain characters that are allowed in URIs, but are reserved
> > or excluded in the Namespace Specific String (NSS) of a URN (in being the
> > suffix, the Category URI becomes part of the NSS in the resulting URI).
> >
> > For example, consider a Category URI using the http scheme, e.g.,
> > "http://example.com/MyCategory";. The "/" characters in the URI are reserved
> > characters for a URN and RFC 2141 (which defines the URN syntax) says
> > "developers SHOULD NOT use these characters in unencoded form". The draft for
> > an update of RFC 2141, draft-ietf-urnbis-rfc2141bis-urn-02, goes further in
> > disallowing an unencoded "/" in the NSS. Thus for the concatenation to be a
> > valid URI now and in the future the "/" characters must be substituted with
> > %2F. In general, any character in the Category that is reserved or excluded for
> > URNs must be %-encoded in the concatenation.
> >
> > To address this problem XACML could either:
> >
> > (1) specify in 4.5 Step 1.d. that reserved and excluded characters in the
> > Category must be %-encoded in the concatenation, or
> >
> > (2) restrict the URIs of categories to be URNs, or
> >
> > (3) use a separate, optional XML attribute to hold the prefix, i.e., in each of
> > the six places where a Category attribute appears add a CategoryPrefix XML
> > attribute alongside it. The section 4.5 mapping would populate the
> > CategoryPrefix attribute instead of concatenating. AttributeDesignator and
> > AttributeSelector (two of the six places) would only match XACML attributes
> > with the same CategoryPrefix.
>
> Two more possible solutions:
>
> (4) Change the type of the Category and XPathCategory XML attributes to
> normalizedString. This works provided the proposal to compare URIs code-point
> by code-point is accepted.
>
> (5) Change the type of the Category and XPathCategory XML attributes to a
> list of anyURI, with comparisons treating the list as ordered. This has the
> advantage of category identifiers still clearly being URIs. The procedure
> for generating an administrative request would put the "delegated:" URI
> at the front of the list. The trailing ":" wouldn't be needed.
>
> I now prefer (5) over (3).
>
> Regards,
> Steven
>
> > Personally, I would go with (3). It is more flexible and easier for
> > implementors to get right compared to (1). It would also help to resolve a
> > problem I raised previously with respect to an original access request that
> > contains an <Attributes> element with a category that is the same as the
> > category of another <Attributes> element in the same request except for the
> > prefixing of "urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:" (an
> > email entitled "Multiple Decision Requests During Reduction"). Under (3), this
> > would be two <Attributes> with the same category, only one of which also has a
> > CategoryPrefix attribute. Either CategoryPrefix could be banned in access
> > requests, or it could be ignored when deciding whether there were any
> > duplicated categories in an access request.
> >
> > Regards,
> > Steven