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: xacml, policy, issuer, combinator parameters...

The purpose of this note is to argue where the issuer of a policy should 

I believe we all agreed that the PDP somehow has to be able to associate 
an issuer with a policy, and it's only a matter whether we add it 
explicitly to the policy itself or whether we use a separate external 
element that links the policy (through a reference) and the issuer info.

First there is the observation, that we could rewrite the schema such 
that we use external associations for all the policy content. The policy 
itself would then consist of only a reference, and all other policy 
elements/attributes would be bound to that policy reference through 
external associations. This would work as long as the entity that has to 
use the policy information "knows" where the associations are that it 
needs to crunch. If that entity is the combining algorithm, then the 
parameters are an easy vehicle to use for the associations that the 
combining algorithm needs.
Note that this observation is equally valid for the policy target 
element as for the issuer...

The only thing left are the practical, pragmatic, philosophical and 
religious reasons why certain policy elements should be grouped together 
in one envelope or why others should be separated out in externally 
maintained associations.

First "my" philosophical/religious reason to make the policy and issuer 
inseparable, are based on the believe that there is no policy statement 
without an issuer - it just doesn't make sense. There is alway some 
subject (implicitly) associated with a statement. The only reason we 
have been able to ignore the issuer so far, is that the local "PDP" (or 
how ever we want to call that local authority) has been the implicit 
issuer of all the policies that it considers.
Which would point at another criteria for inclusion: a policy element 
should (at least) include all elements/attributes that make it a 
"policy".  In other words, a policy should be a tuple that conveys the 
"semantical" meaning of a policy... For me this would put the target and 
rules back into the policy envelop ... as well as the issuer.

The other parallel I see is with the attributes we have, which also have 
issuers associated with them. The attributes came in through some form 
external assertions, like SAML. Why did we decide to add the issuer to 
the attribute, and why didn't we add attribute issuer as a combining 
algorithm parameters?
The reason for the latter is probably more historical ... but suppose we 
could do it over again and start from scratch: where should the 
attribute-issuer association be kept?

The practical/pragmatic reason is of course that we wouldn't have to 
make any schema changes to the PolicySet/Policy type elements, which is 
only a valid argument if we have to cut corners and such...
A related reason would be that we are still uncomfortable with all this 
delegation stuff, and that a combining algorithm parameter solution 
allows us to side-step the whole issue at the expense of some elegance 
and purity...

In conclusion, adding the policy-issuer association as a combining 
algorithm parameter would work but IMHO it is a butt-ugly hack... and I 
would prefer to add the issuer info to the policy element.

Regards, Frank.

PS. Polar mentioned that there are possible "issues" when the issuer 
would be included in the policy, but without giving more details it 
sounds like FUD to me ;-)


Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory

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