[xacml] Changing subject-category from XACML Attribute to XML attribute

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

Colleagues,

We have received related comments on this topic: #39 and #40,
which are included below.  Attached to #40, I have listed the
specific changes that would be required in the spec if we change
the Context subject-category Attribute to an XML attribute of the
Context <Subject>.  While there are quite a few changes, they are
not complicated, and the result is a simpler specification
overall.

Opinions were divided at the Comments Subcommittee Meeting on
11/25/02, and we also felt we should hear from more of the TC
membership on this topic before resolving these comments.

Please respond with your opinions on this.

Anne Anderson
=============================================================================
0039. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00067.html
Subject: subject-category as attribute, rather than <Attribute>
From: John Merrells <merrells@jiffysoftware.com>
Date: Wed, 20 Nov 2002 22:24:12 -0800

I can see why the subject-category attribute has been modelled
the way that it has, as an <Attribute> of the <Subject>
element. But how about modelling it as an XML attribute of the
<Subject> element instead?

<Subject Category='...:access-subject'>...</Subject>

This would enforce the constraint that there be only one subject-
category attribute in the XML Schema. This would also make
implementing a request processor a little simpler. And, I think
would make understanding this feature of the standard simpler.

CATEGORY: Alternative.
STATUS: Discussed 11/25/02.  Bring this up on the XACML list
for more discussion.  Would require a schema change, but would be
more consistent and possibly more efficient to search.
SEE ALSO: #40
RESPONSE: 
ACTIONS: 
=========================================================================
0040. http://lists.oasis-open.org/archives/xacml-comment/200211/msg00069.html
Subject: Section 6.2
From: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: Thu, 21 Nov 2002 16:26:00 +0900

Section 6.2 says that every <Subject> element MUST contain one
and only one <Attribute> with AttributeId
"urn:oasis:names:tc:xacml:1.0:subject:subject-category".

I'm wondering if this contradicts another sentence, which starts
with "If this attribute is not present in a given <Subject>
element"

The former means that there must be a single attribute
representing the subject category.  On the other hand, the latter
means that it's optional.

Is this okay?

CATEGORY: Inconsistent.
STATUS: Discussed 11/25/02.  Bring this to the XACML list for
further discussion.
SEE ALSO: #39
RESPONSE:

DISCUSSION (11/25/02): Two options
1) Change "MUST contain one and only one" to "MUST contain no
   more than one" in Section 6.2 pdf:2553.

2) Make subject-category attribute required in the Request
   context schema (see f. below).  Make following associated
   changes in the specification:

a.  2.4 Multiple subjects, pdf:419-420

  An XML attribute called "SubjectCategory" is used to differentiate
  between subjects acting in different capacities.  Some standard
  values for this XML attribute are specified, and users may define
  additional ones.

b.  4.2.2 Example request context, pdf:924:  change
  [05]	<Subject>
  to:
  [05]	<Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

c.  4.2.2 Example request context, delete lines pdf:929-937,
  [06]-[14] that currently specify the subject-category
  attribute.

d. 4.2.2 Example request context, change pdf:1005-1009 from:

  05]-[37] Subject attributes are placed in the Subject section of
  the Request.  Each attribute consists of the attribute
  meta-data and the attribute value.

  [06]-[14] Each Subject section must have one and only one
  subject-category attribute.  The value of this attribute
  describes the role that the subject plays in making the
  decision request. The value of "access-subject" denotes the
  identity for which the request was issued.

  to:

  05]-[37] Subject attributes are placed in the Subject section
  of the Request.  Each XACML attribute consists of the attribute
  meta-data and the attribute value.  Each Subject element has an
  associated "SubjectCategory" XML attribute.  The value of this
  attribute describes the role that the subject plays in making
  the decision request. The value of "access-subject" denotes the
  identity for which the request was issued.

e. Change 5.30 Complex type SubjectAttributeDesignatorType,
   pdf:2354-2364, to:

   5.30.Complex type SubjectAttributeDesignatorType

   The SubjectAttributeDesignatorType complex type extends the
   AttributeDesignatorType complex type.  It is the base type for
   elements and extensions that refer to named categorized subject
   attributes.  A named categorized subject attribute is defined
   as follows:

   A subject is represented by a <Subject> element of the
   <Subjects> element in the <xacml-context:Request> element.
   The <Subject> element contains a SubjectCategory XML
   attribute with a default value of
   "urn:oasis:tc:xacml:1.0:subject-category:access-subject".

   A categorized subject is a subject that is identified by its
   particular subject category XML attribute.
  
f. Section 6.2 Element <Subject>.  Insert following into schema
   fragment just before pdf:2549:

   <xs:attribute name="SubjectCategory" type="xs:anyURI"
                 use="optional"
   default="urn:oasis:tc:xacml:1.0:subject-category:access-subject"/>

g. Section 6.2 Element <Subject>.  Insert following between
   pdf:2550 and pdf:2551:

   SubjectCategory [Optional]

   This attribute SHALL specify the subject category of the
   associated <Subject> element.  This attribute indicates a role
   that the <Subject> entity plays in making the access request.
   If SubjectCategory is not supplied, then its default value
   SHALL be
   "urn:oasis:tc:xacml:1.0:subject-category:access-subject",
   indicating that the subject is the entity ultimately
   associated with initiating the access request.

h. Section 6.2 Element <Subject>, delete pdf:2553-2558.  Change
   pdf:2559 to:

   Typically, a <Subject> element will contain an

i. Section 6.2 Element <Subject>, delete pdf:2562-2563 ("No more
   than one..."

j. Delete Section 13.9.4 Subject Attributes

k. Add "SubjectCategory" to Section 8.1 Extensible XML attribute
   types.  Delete Section 8.2 Extensible XACML attribute types.

l. Remove "Urn:oasis:names:tc:xacml:1.0:subject:subject-category      
   M" line from 10.3.5 Attribute

m. Remove the four ":subject-category:" attribute identifiers
   from the table in 10.3.6 Identifiers.

n. Add new Section

   10.3.7 XML Attribute Values

   The implementation MUST use the following identifiers as
   values for the <Subject> SubjectCategory XML attribute as
   specified by XACML.  This requirement pertains primarily to
   implementations of a PAP or PEP that use XACML, since the
   semantics of this attribute are transparent to the PDP.

   urn:oasis:names:tc:xacml:1.0:subject-category:access-subject M
   urn:oasis:names:tc:xacml:1.0:subject-category:codebase       O
   urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject O
   urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject  O
   urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine O

o. Change B.2 Access subject categories, pdf:4388 from "If
   subject category is not specified, then this is the default
   value." to "If SubjectCategory is not specified, then this is
   the default value".

p. B.5 Subject attributes, delete pdf:4390-4391:

   This identifier indicates the subject category.
   "access-subject" is the
   default. urn:oasis:names:tc:xacml:1.0:subject:subject-category

ACTIONS: