[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 reside. 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]