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