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] Erik absent from focus group this week


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?

Ron Williams
Sr. Enterprise Architect
IBM Tivoli Security & Privacy

Tim Moses <tim.moses@entrust.com>

07.12.05 09:47 AM

"'mirty@sics.se'" <mirty@sics.se>, xacml@lists.oasis-open.org
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.

-----Original Message-----
From: mirty@sics.se [
Sent: Monday, July 11, 2005 10:13 AM

To: xacml@lists.oasis-open.org

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


I will not be able to join the focus group meeting this week and I will also not be able to work on the delegation draft until after the next TC meeting.

For the next draft I intend to focus on making the descriptive text more clear and consistent. Although the processing model and schema fragments are consistent now (as far as I know), the descriptive text is still a bit messy. We need to come up with consistent terminology and mental models to use for the descriptions. Any suggestions are most welcome, but lacking any input, I will do my best on my own. :-)

I am not planning to add any new features for the next draft, since I would rather wait with that until the basics are well defined and explained.

Best regards, Erik

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS

at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

S/MIME Cryptographic Signature

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