xacml — archive

[xacml] [schema] subcommittee minutes for 10 June 2002

From: Anne Anderson <[email protected]>
To: [email protected]
Date: Mon, 10 Jun 2002 21:21:00 -0000

Attendees: Tim, Simon, Carlisle, Michiharu, Polar, and Anne (humble scribe) 1. We APPROVED the minutes from the 3 June 2002 subcommittee meeting ( http://lists.oasis-open.org/archives/xacml/200206/msg00009.html ). 2. We discussed various issues with the RequestContext. Anne will submit a revised RequestContext proposal to the list (DONE: http://lists.oasis-open.org/archives/xacml/200206/msg00033.html ). The issues and their resolutions follow: ContextResource(s): - Only one resource can be specified in a RequestContext. ContextAction(s): - There is only one action string in a RequestContext. This action string may be parseable into compound actions, but such parsing is application-dependent and is transparent to the PDP. ContextPrincipals: - We decided to continue to treat PrincipalID/NameIdentifier as a distinguished element under Principal, rather than putting the NameIdentifier information into an Attribute. The reason is that a Principal can have at most one PrincipalID, but other attributes are arbitrary. If there is a PrincipalID, then its NameIdentifier must match any Holder element in the Principal's <xacml:Attribute>s. - <ContextPrincipals> can contain multiple <Principal> elements. Each such element is associated with an entity that is involved in making the access request. - The role/function/Nature/PrincipalType of the entity's involvement is described using an XML attribute of the <Principal> element of type anyURI. The default value of this XML attribute is a value denoting the "requesting entity"/Subject/most immediate subject involved in making the request. Tentatively the name of this XML attribute is "xacml:ContextSeat". Tentatively, the default value for this attribute is "xacml:AccessSubject". - The PDP does not need to understand the semantics of any "xacml:ContextSeat" attribute values. It merely matches whatever the policy specifies against whatever the PEP supplies. ContextOther: - ContextOther contains <Attribute>s. Each Attribute has a holder that is not involved in making the access request. Each <ContextOther> <Attribute> is an arbitrary assertion that may be useful or required in deciding to grant access. - Simon's example policy is "Carlisle is allowed access to file X if Tim is in the office". In a request satisfying this policy, "Carlisle" and his attributes would be placed under <ContextPrincipals>. The attribute saying Holder "Tim" is "in his office" would be placed under <ContextOther> xacml:Attribute/xacml:AttributeDesignator: - AttributeFamily will be re-named AttributeNamespace to match the SAML usage. AttributeName (string) and AttributeNamespace (anyURI) will NOT be combined, but will be kept separate for consistency with SAML. Both AttributeName and AttributeNamespace are REQUIRED, but all other XML attributes of an Attribute or AttributeDesignator are OPTIONAL. AttributeNamespace has the semantic of "namespace authority" for the AttributeName value. - An <xacml:AttributeDesignator> element itself will never appear in the RequestContext, but only in the core. It describes an <xacml:Attribute> whose <xacml:AttributeValue> is expected to be found in the RequestContext [or via an AttributeAuthority???]. - An <xacml:Attribute> may appear in the RequestContext, but not in the core. The core may compare an <xacml:AttributeDesignator> with an <AttributeValue> or with another <xacml:AttributeDesignator>. - <Holder> is optional when the Attribute appears under a <Principal> element that has a <PrincipalID>. If it appears under a <Principal> element with a <PrincipalID>, then the <NameIdentifier> of the <Holder> MUST match the <NameIdentifier> of the <PrincipalID> element. - Simon will re-issue his proposal for AttributeDesignator (DONE: http://lists.oasis-open.org/archives/xacml/200206/msg00032.html ) 3. Tim plans to issue version 14 of the xacml draft specification and schema by 14 June 2002. Please submit any updates that need to go into this version to the list as soon as possible. In version 14, "obligations" will be treated as "optional" and not "mandatory-to-implement". If and when IBM issues a statement that XACML implementations can obtain a royalty-free license for any IBM intellectual property that IBM claims is infringed by use of XACML obligations, then the intent is to make obligations mandatory-to-implement at that time. 5. Carlisle noted that ContentGuard has posted a note to the Rights Language TC page saying they have intellectual property that "may necessarily be infringed by the use of a rights expression language, such as the rights expression language being promulgated by the RL TC, to implement digital rights management technologies." ( http://www.oasis-open.org/committees/rights/documents/oasisrltc.shtml ) 6. The meeting adjourned at 11:30am Eastern Daylight Time (15:30 GMT). Anne -- Anne H. Anderson Email: [email protected] Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692