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
|  |
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
S/MIME Cryptographic Signature
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]