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

[Tim Moses <tim.moses@entrust.com>]

Title: 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 [mailto: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

All,

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