Re: [xacml] xacml, policy, issuer, combinator parameters...

[Frank Siebenlist <franks@mcs.anl.gov>]

If you're accepting that that there is an issuer/authority associated 
with a policy, then it becomes irrelevant to the *current* discussion 
why that "who" is the chosen issuer or how you determined that "who". 
The issue at hand is where you keep that association.

If you're not accepting that there is an issuer associated with a 
policy, then we also have no discussion...

I simply don't understand why you even want to have a discussion of how 
a policy "written" by polar becomes "mine". The reduction: polar *says* 
A & frank *believes* polar => frank *says* A...  is at the heart of the 
proposed scheme.... but never mind, I don't want to discuss that here as 
it is not part of the current issue.

I rest my case.

-Frank..





Polar Humenn wrote:

>comment, of course, by me, :) in line.
>
>
>On Thu, 15 Jul 2004, Frank Siebenlist wrote:
>
>  
>
>>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.
>>    
>>
>
>There in lies the rub.
>
>The PDP "issues" the policy, but it almost certainly didn't write it.
>
>You can imagine a library where policies are stored and integrity
>protected, but not "issued". The effectively are "issued" when they are
>placed inside a PDP.
>
>My problem with the <Issuer> being inside the policy is taking the policy
>and when "accepting" it into the PDP, changing the <Issuer> to something
>different.
>
>When you add a CombinerParameter into a policyset and associate it with a
>particular policy, you are doing that at policyset writing time,
>effectively "accepting" the policy into the policy set.
>
>Note, this approach will work for rules inside a <Policy> as well, with no
>great effort, To get the same capabilityh you would have to add and
><Issuer> to a <Rule> as well.
>
>
>  
>
>>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 <Target> of a policy is not so much meta-data of the policy as it is a
>predicate of the policy. The semantics of the target is that the predicate
>specified as such must be satisfied in order for the policy to be
>considered applicable. (whether there is a further applicable decision is
>another question).
>
>The only thing we might argue is an attribute or meta data of the policy
>that is INSIDE the policy is the policy-id. It has no functional aspect to
>the evaluation of the policy itself. However, the only reason it exists is
>to reference it. And there are definite problems with it. (I don't like
>Policy/Set Ids/References, but I lost that battle) :)
>
>  
>
>>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 <Attribute> is part of the Request Context, and as such the issuer of
>the attribute is stated in the ReqeustContext, not a Policy.
>
>The CombinerParameters, which are inside a policy or policyset, associate
>values to Policies, not Attributes found in the RequestContext.
>
>  
>
>>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 ;-)
>>    
>>
>
>One of the chief issues I keep on about is the problem with conflicting
>information.
>
>Say there is a policy A written by Bob. Is Bob the issuer?
>
>Say Alice, a policy administrator, pulls policy A out of a library, and
>puts in into her PDP? Is the issuer Bob? Or is the issuer Alice? Is Alice
>allowed to Change the <Issuer> element in the policy to herself?
>
>Let's say Alice is writing a PolicySet. The point at which she "accepts" a
>policy into a PolicySet is the point in which she places the policy (or,
>gak! its reference) into the PolicySet. That is the point in which she
>decides who is the effective issuer.
>
>If she got Policy A (with <Issuer>Bob</Issuer>) she is mandated to either
>accept the fact that Bob is the issuer (and whatever that really means),
>or not accept it. Alternatively, she can change (or copy) and change the
><Issuer> effectively rewriting the policy.
>
>These are the steps I don't like:
>
>1. You are mandated to accept the fact that Bob is the issuer or not.
>   period.
>     (reason: I don't want you telling me how to administer policies).
>2. The fact that you can "change" a policy once the effective meaning of
>   that policy is established within the structure.
>
>You have to do 2 if you don't adhere to 1.
>
>Second of all, this <Issuer> element is *only* going to have meaning in
>the application of these fancy, iterative, Combining Algorithms that pay
>attention to this element.
>
>Therefore, putting the issuer in the combiningParameter for that
>particular combining algorithm makes more sense.
>
>Cheers,
>-Polar
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>
>  
>

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