Re: [xacml] proposal for action-id, subject-id, and required Attributes

[Polar Humenn <polar@syr.edu>]

Anne, again, just requiring the Subject to have "one other" attribute,
which is "typically" the "subject-id", doesn't really buy you much.

I suggest that we should take a stance of being consistent across all
subjects, actions, and resources. For each, either that no attributes are
guarranteed to be there, or they all have at least one attribute available
and we know explicitly what that attribute is.

-Polar

On Fri, 30 Aug 2002, Anne Anderson wrote:

> Issue:
>
>   I am proposing that we not require a <Request> <Resource> to
>   contain a "resource-id" Attribute, but instead that it MUST
>   contain one or more <Attribute>s (not specified which) OR a
>   <ResourceContent> element.  Previous e-mail describes this.
>
>   But we are still left with which <Attribute>s, if any, are
>   required for the <Subject> and the <Action>.
>
> Proposal:
>
> SUBJECT
>
>   Set <Subject> <Attribute> minOccurs=2, and use the following
>   wording:
>
>   "Every <Subject> element MUST contain one and only one
>   <Attribute> with AttributeId equal to
>   "urn:oasis:names:tc:xacml:1.0:subject:subject-category".  This
>   attribute indicates the role that the parent <Subject> plays in
>   making the access request.
>
>   Every <Subject> element MUST contain at least one other
>   <Attribute> that describes the parent <Subject>.  Typically, a
>   <Subject> element will contain an <Attribute> with AttributeId
>   equal to "urn:oasis:names:tc:xacml:1.0:subject:subject-id"
>   describing the identity of the parent subject.  A <Subject> may
>   contain any number of other Attributes.
>
>   More than one <Subject> element may contain an <Attribute> with
>   the same value for "subject-category".  For example, the user
>   executing the application making the access request may have
>   authenticated using an e-mail name and an X500 Distinguished
>   Name.  Attributes issued to the user under the e-mail name
>   might be included in one <Subject> element along with a
>   "subject-id" Attribute containing the e-mail name, while
>   attributes issued to the user under the X500 name might be
>   included in another <Subject> element along with a "subject-id"
>   Attribute containing the X500 name.  Both <Subject> elements in
>   this case, however, would have the value
>   "urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject"
>   for the subject-category Attribute."
>
> ACTION
>
>   Set <Action> <Attribute> minOccurs=1, and use the following
>   wording:
>
>   "Every <Action> element MUST contain one and only one
>   <Attribute> with AttributeId equal to
>   "urn:oasis:names:tc:xacml:1.0:action:action-id".  This
>   attribute specifies the action to be performed on the
>   resource.
>
>   If there is no separate value for the action (for example, the
>   action is implied by the resource-id), then an action-id
>   Attribute with a value of
>   "urn:oasis:names:tc:xacml:1.0:action:implied-action" MUST be
>   used.
>
>   An <Action> element MAY contain an <Attribute> with AttributeId
>   equal to
>   "urn:oasis:names:tc:xacml:1.0:action:action-namespace".  This
>   attribute specifies the namespace to which the action-id
>   belongs.
>
>   An <Action> element MAY contain any number of other
>   <Attribute>s.
>
> Discussion:
> SUBJECT
>
>   I think a <Subject> that does not have at least one Attribute
>   is meaningless from a policy point of view: it could never
>   affect the result of a valid XACML Policy.  Possible
>   counter-example might be something like "Permit access if the
>   CodeSource was NOT signed by XYZ.corp", but in that case, I
>   think the same result is achieved by not having a <Subject>
>   with a subject-category of "codesource" at all.
>
> ACTION
>
>   Hal has suggested that an Action should not have attributes,
>   other than Id and optional NameSpace.
>
>   An example of an Action attribute might be an assertion that
>   the Action has been approved by the requester's manager.  Given
>   this type of use case, I do not think we should prevent XACML
>   policy writer's from using Action attributes.
>
> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>