OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  "Web Friendly" Policy Ids

    Posted 03-24-2011 14:56
    Paul, On the last call you made a remark about making XACML more web friendly by allowing policies to be retrieved by dereferencing their Policy ID which would be an HTTP URI. (If I have this wrong, please correct me.) I would like to make two observations about this. First, it has generally found to be operationally inconvenient to put the fully qualified name of any file inside the file. There are many reasons which it may be desirable to change the location of a file, but undesirable to modify the file contents. XML Schema, for example, recognizes this by defining the value of xsi:schemaLocation as merely a hint as to where the schema may be found. My second comment is that I did look at what 3.0 (and 2.0) says about Policy Id. Policy ID (and Policy Set ID) are required and defined as type anyURI. The values are required to be unique within any PDP and it specifically says that: If the policy identifier is in the form of a URL, then it MAY be resolvable. It seems to me that this allows you to do what you want to using the current spec, while others are free to use a different scheme. Hal


  • 2.  RE: "Web Friendly" Policy Ids

    Posted 03-24-2011 16:07
    I agree that one could implement XACML policy ids and dereferencing mechanisms in a very web-compatible manner, and nothing in the spec prevents this.

    I haven't analyzed all the use cases, so I'm not prepared to pinpoint any barriers to interoperability (if any) due to the current specification of policy ids and references. But just as one example, if I receive a policy-set that contains

    <PolicyIdReference>policy1</PolicyIdReference>

    and I try to interpret that as a relative URI, what is the base URI? Unless I understand the conventions of the policy writer I am lost. If in the same policy-set file there is a <Policy PolicyId="policy1"> I can make a good guess that this is the intended target, but it is still only a guess. Nothing in the specification supports this inference.

    Again, nothing prevents someone from adopting conventions that allow unambiguous specification and resolution of policy ids, but that is different from having a spec that reduces or eliminates ambiguity.

    Regards,
    --Paul