OASIS eXtensible Access Control Markup Language (XACML) TC

Anne,

I'm sorry, just keep forgetting that "reply-to" is not set to the list.

thanks
argyn

On 3/16/07, Anne Anderson 

Anne,

I also think that a simple solution is to require that xxxx and yyyy
must be equal.

But I can also imagine that people want the xxxx to provide some
information on how to resolve it. For instance if yyyy is just a random
UUID, it might be difficult to resolve in an environment where there are
multiple potential sources of policies. But, perhaps one should not be
using random policy identifiers in that case? So, one should make the
yyyy such that it is resolvable in the particular environment.

Also, I don't think it would hurt to allow xxxx and yyyy to be not
equal. If we allow that, in this case we should stick with that only and
not add other elements to do mappings in the core. I think these
mappings elements would just shift the problem to the new elements.
Policy provisioning is inherently at a more implementation specific
level than the XACML core spec. Rather we should leave it to
implementors and users to profile the resolving. And this could perhaps
be something which could be part of any policy provisioning standards
work, should the TC pursue it?

For instance, a policy provisioning profile might require that policy id
(or perhaps the reference only) have some specific form, like:

urn:xacml:policyref:sics.se:j37r984jg83hf87

A part of the reference, "sics.se" would be used to look up in a table a
web service where the policy can be retrieved using the (yet to be
defined) standard provisioning protocol.

So, in summary, for the core IMHO: Either a) require that xxxx and yyyy
are equal and let users use an yyyy which they can resolve, or b) let
them be unequal but we do not add new elements/attributes to do mappings.

In either case, possibly define something in a policy provisioning profile.

There is a difference though between the core and the SAML profile. The
SAML profile is more specific since in this case the location of policy
is known: it's embedded in the SAML document. So, in this case we can
profile the resolving within the SAML profile document.

One requirement, which I think I prefer is to require that xxxx and yyyy
are equal. If for some reason this would not work for people, then we
would have to do the mappings, which would be a part of the SAML profile
(and no part of this should be in the core). A profile for the xxxx
format (as I suggested above) is a third possibility, but I don't see
any advantage of this over just requiring equality between xxxx and yyyy.

So, in summary for the SAML profile IMHO: first preference: require that
xxxx is equal to yyyy. If this really doesn't work, do mappings with
elements in the SAML profile schema.

Best regards,
Erik


Argyn wrote:
> Anne,
>
> I'm sorry, just keep forgetting that "reply-to" is not set to the list.
>
> thanks
> argyn
>
> On 3/16/07, Anne Anderson 

In today's TC call I promised to capture a quick summary of the use-cases I
covered. Essentially, there are two main uses I have seen where reference
identifiers and policy identifiers don't match up:

  1. A policy is managed at a single point, but pushed to multiple PAPs
     for use. This may be because some PAPs are accessible only from
     specific domains, specific applications, etc. The PAPs provide the
     access to the same policy via different protocols (e.g., http, ldap,
     local filesystem, ebXML Registry, custom application, etc.). The
     policies that reference this policy all want to use different
     reference identifiers because they want to encode details of the
     resolution mechanism. For instance the three reference identifiers

       http://example.com/site/policies/global-policy.xml
       /net/server1/files/policies/gp1.xml
       svn://server1/site/policies/global.xml

     could point to the same policy. If the reference and policy identifiers
     must match, then this cannot be done. Instead, the referring policies
     must all use the same identifier, and their PDPs must each be configured
     to know how to do the mapping. This assumes, of course, that all
     references from a given PDP use the same protocol, and don't host
     policies that want to use different protocols in different scenarios.

  2. A policy is managed at a single point, but different entities or
     domains know this policy by different identifiers. This could be because
     of naming conventions (e.g., at Sun we call this the "corporate policy"
     but at Example.com they call it "legal policy") or for good object
     design reasons (i.e., I would like the same policy that represents
     mixed logic to be referenced by different names when a specific use
     is called out, like "site access" or "weekend access" referring to
     the same policy). This does not have the functional requirements of
     case 1, so it's just a naming and design issue that is impacted by
     requiring all reference and policy idetifiers to match.


seth