OASIS eXtensible Access Control Markup Language (XACML) TC

RE: [xacml] Erik absent from focus group this week

  • 1.  RE: [xacml] Erik absent from focus group this week

    Posted 07-12-2005 21:06
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: RE: [xacml] Erik absent from focus group this week



    <2c>

    In this context, is there ever a case where the delegate/issuer is not a delegate? If there is not, I would prefer the more explicit "delegate" to the more general "issuer."

    I agree with "administrative" vs. "administration."

    I am troubled by the <LaterDelegateAttributeDesignator>. This may be abject ignorance or density on my part. However, does "Later" here seems to imply that it will be identified as a delegate later in  processing, but the text says "The previous delegate is transformed into a later delegate and the issuer of Policy 2 is the new delegate" which implies that it should be called "PreviousDelegate" instead?

    </2c>
    Ron Williams
    Sr. Enterprise Architect
    IBM Tivoli Security & Privacy
    +1.512.838.0073
    +1.512.633.7711
    ron.williams@us.ibm.com




    Tim Moses <tim.moses@entrust.com>

    07.12.05 09:47 AM

    To
    "'mirty@sics.se'" <mirty@sics.se>, xacml@lists.oasis-open.org
    cc
    Subject
    RE: [xacml] Erik absent from focus group this week





    All - I have given a little thought to Eric's question about the naming of "delegate".  My preference is to change "delegate" to "issuer" (see footnote).  Of course, there is potential for confusion with the <PolicyIssuer> element.  But, when seen in context (inside the <Target> element) its meaning should be clear.

    An alternative for <PolicyIssuer> would be <IssuerOfThisPolicy>.  But, my preference is to leave it as <PolicyIssuer>.

    Perhaps we should talk about "administrative" policy, instead of "administration" policy, to align with "administrative" request, since "administration" request doesn't seem to convey the meaning well.

    Having evaluated a "pending policy", i.e. one that it is not "in force" because it contains a <PolicyIssuer> element, the contents of the <PolicyIssuer> element would be placed in the <Issuer> element of the administrative request context.  The context handler may include additional verified attributes of the "policy issuer".  As currently defined, we are allowing the issuer of a policy to include others of its attributes in addition to its names.  We should mention that the context handler should only include attributes that it has verified (by unspecified means).

    Please "chime in" if you disagree.

    All the best.  Tim.

    Footnote: the elements <Delegates>, <Delegate>, <DelegateMatch>, <DelegateAttributeDesignator>, <LaterDelegateAttributeDesignator>, <xacml-contect:Delegate> and <xacml-contect:LaterDelegate> are all impacted in a corresponding way.