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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] Decision required: Issue#70: Must Policy[Set]Id matchvalue used in a corresponding Policy[Set]IdReference?


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 <Anne.Anderson@sun.com> wrote:
>> Would you be willing to post this to the list?  The discussion should be
>> public and on record for future reference to why we made the decision.
>>
>> Thanks,
>> Anne
>>
>> Argyn wrote:
>>
>> > xxxx and yyyy should be equal, imho. that's how it's done in
>> > conformance tests, and it's very logical to me.
>> >
>> > thanks
>> > argyn
>> >
>> > On 3/16/07, Anne Anderson <Anne.Anderson@sun.com> wrote:
>> >
>> >> PROBLEM
>> >>
>> >> The question is, when one policy references another, as in
>> >>
>> >>     <PolicySet ...>
>> >>        <Target .../>
>> >>        ....
>> >>        <PolicyIdReference>xxxx</PolicyIdReference>
>> >>        ....
>> >>     </PolicySet>
>> >>
>> >>     referenced policy:
>> >>
>> >>    <Policy PolicyId="yyyy">
>> >>        ....
>> >>    </Policy>
>> >>
>> >> whether "xxxx" must equal "yyyy".
>> >>
>>
>> -- 
>> Anne H. Anderson               Anne.Anderson@sun.com
>> Sun Microsystems Labs          1-781-442-0928
>> Burlington, MA USA
>>



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