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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: A Problem with the "delegated:" Prefix

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.

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.


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