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

[Anne Anderson <Anne.Anderson@Sun.com>]

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: 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