OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] Committee Specification vote/Updated Change Requests


The current list of Voting Members from the XACML TC Web Page,
along with current indications of whether people plan to attend
are:

    Voting Members
    =======================================
Y   Ken Yagen,                   Crosslogix
Y   Daniel Engovatov,            Crosslogix
    Hal Lockhart,                Entegrity
Y   Carlisle Adams,              Entrust
Y   Tim Moses,                   Entrust
Y   Don Flinn,                   Hitachi
Y   Konstantin Beznosov,         Hitachi
Y   Michiharu Kudoh,             IBM
    Steve Anderson,              OpenNetwork
    Simon Godik,                 Overxeer
Y   Bill Parducci,               Overxeer
Y   Polar Humenn,                Self
    Suresh Damodaran,            Sterling Commerce
Y   Anne Anderson,               Sun Microsystems
N/A Piras Vilandai Thiyatarajan, Sun Microsystems
Y   Gerald Brose,                Xtradyne

Piras resigned, so he should not be counted.  Simon and Hal
probably just have not had a chance to respond yet - I can't
imagine they would not be on this call :-)

But, even without Simon and Hal, we have 11 out of 15 members who
have positively indicated that they WILL be present.  So unless
we get some unexpected NO votes, I think we could vote for
Committee Specification on 7 November as long as we can resolve
the remaining issues in time for Simon and Tim to issue the
"Final Draft" by close of business on Wednesday.

Attached is a new Change Requests list, containing only the
unresolved Change Requests.  A couple of these we probably don't
have to resolve before public review.  But I want everyone to be
aware of what remains.

In particular, could people respond to the two proposed
resolutions to "0162: [Polar] [Schema/Text Change] Subjects",
since that is the immediate sticking point.

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

Title:   Change Requests Set 5
Author:  Anne Anderson
Version: 1.2, 02/11/05 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests5.txt

This file contains all Change Requests not fully resolved as of 5
November 2002.  See
http://lists.oasis-open.org/archives/xacml/200210/msg00214.html
and
http://lists.oasis-open.org/archives/xacml/200211/msg00029.html
for previous Change Requests against v0.18c.doc that have been
resolved.

Includes e-mail up through
http://lists.oasis-open.org/archives/xacml/200211/msg00067.html
=============================================================
CHANGE REQUESTS

1.SUMMARY
=========

1.1 ACTION ITEMS
================
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
  ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146

1.2 UNRESOLVED
==============
Note: 92, 156, 154, and 162 are inter-twined.

0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
  STATUS: UNRESOLVED. Waiting for CR#0146(11/4)  See RESOLUTION.
0146: [Polar] CR 144: function "present" needs to be fixed.
  STATUS: UNRESOLVED (11/4).  Need semantics in QualifiedSubjectAttributeDesignator.
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
  STATUS: UNRESOLVED.  See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
0156: [Seth Proctor] ObligationType
  STATUS: UNRESOLVED
0157: [Steve Hanna] Glitch in moving from decimal to double
  STATUS: UNRESOLVED
0162: [Polar] [Schema/Text Change] Subjects
  STATUS: UNRESOLVED.

1.3 RESOLVED IN SUBCOMMITTEE, BUT NEED QUORUM VOTE
==================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
  STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4).  See RESOLUTION.
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
  STATUS: NEEDS QUORUM.  RESOLVED (NQ 11/4).  Use xs:string" in both places.
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See RESOLUTION.
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4)
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.

1.4 RESOLVED
============
None

=========================================================================
2. DETAILS
=========================================================================
0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146
  STATUS: UNRESOLVED. Waiting for CR#0146(11/4)  See RESOLUTION.
  SEE ALSO: CR#0146

  RESOLUTION:
  This draft resolution was accepted in general (Q 10/31), but it
  needs to be updated based on the resolution to CR#0146:
  - Impact of MustBePresent XML attribute
  - Impact of missing attributes in a given <Subject> block in
    evaluating QualifiedSubjectAttributeDesignator.

  TEXT LOCATION: Section 7.9 "Attributes" (v0.18e.doc)

  TEXT CHANGE: Replace current 7.9 with following:
  [I have updated following with section#'s from v0.18e.doc.  Tim
  has already incorporated much of this. -Anne]

    7.9 Attributes

    Attributes are specified in the request context and are
    referred to in the policy by the subject, resource, action,
    and environment attribute designators or selectors. Each
    context attribute specifies an AttributeId and a DataType.
    Each attribute desigator specifies an AttributeId and
    DataType. Attribute designators SHALL match attributes by
    using string equality on both the AttributeId and DataType
    values.  Each attribute selector specifies a DataType and an
    XPath expression.  Attribute selectors SHALL match attributes
    by using the XPath expression and string equality on the
    DataType values.

    7.9.1 Attribute Retrieval

    The PDP SHALL retrieve the values of attributes that match
    the particular attribute designator or attribute selector and
    form them into a bag of values with the specified
    DataType. If no attributes from the request context match,
    the attribute shall be considered missing, and an empty bag
    is said to be retrieved.

    7.9.2 Missing Attributes

    The PDP SHALL consider an attribute as missing if it
    evaluates an expression that requires at least one value to
    be present from an attribute designator or selector. In this
    case, the expression evaluates to "indeterminate". The PDP
    may carry the missing attribute upward in its indeterminate
    value in accordance with the XACML evaluation strategy of the
    encompassing expressions, rules, policies, and policy
    sets. If the PDP evaluates its policy or policy set to
    Indeterminate with a missing attribute, the PDP MAY list the
    AttributeId and DataType of that attribute in the result as
    described in Section 7.10 "Authorization decision".  However,
    the PDP MAY choose not to issue such information due to
    security concerns.

  DISCUSSION:
  [Seth]
  Given the original text quoted above, an AD/AS will always
  return a bag, which is always an error to most of the standard
  functions, unless a bag with only one element is considered to
  be the same as a single instance of just the element inside the
  bag.  The text change clarifies this.

  Long discussion questioning rejection of resolution#2.  Simon
  clarified intent of the TC as follows:

  1) Must wrap an AttributeDesignator with *-one-and-only
     function to convert a bag into a single value, or else must
     use AnyOf higher-order function.
  2) Yes, the TC considered the "simplicity" of "implicit" type
     conversion, but felt type consistency was more important.
     There may be a performance overhead, but implementations
     must deal with this.
  3) if new type is defined every type-* function must be
     defined as well

  Polar provided following example of use "anyOf":

  <Apply FunctionId="function:AnyOf">
      <Function FunctionId="function:string-equal">
      <AttributeValue Datatype="....#string">Hello World</AttributeValue>
      <AttributeDesignator ....../>
  </Apply>

  This structure explictly states that if indeed the
  AttributeDesignator returns more than one value, it is your
  *explicit intent* that the boolean is true for any of the
  returned values.

  [Polar, responding to Daniel]
  > In this particular example, *-is-in can be used as well.

  The any-of must take a function that has the type: (a -> a ->
  Boolean)

  The type of *-is-in is ( a -> [a] -> Boolean), where a is a
  primitive type, such as the type of function:string-is-in is:

  (String -> [String] -> Boolean).

  An application of string-is-in would be:

  <Apply FunctionId="function:string-is-in">
      <AttributeValue DataType="....#string">Hello World<AttributeValue>
      <AttributeDesignator ....../>
  </Apply>

  [Polar, responding to Simon]

  > functions that do not take attribute bags as arguments do not
  > care about empty bags.

  Untrue. An or function, for instance, is supposed to go through
  a list of inputs until it finds a true value. If one of those
  inputs fails to find any values, and the MustBePresent
  attribute is false, then an empty bag is returned. This is done
  precisely so that the function may skip over that input and
  continue on (whereas it might choose to do something different
  in an error case). Functions that do not take attribute bags as
  arguments may still need to recognize the special case of an
  empty bag.

  [Seth, responding to Polar] Yes, I understand how anyOf is
  used, but it means that you can't nest Apply blocks that have
  functions that expect single values. Ie, in the example you
  give

  > <Apply FunctionId="function:AnyOf">
  >     <Function FunctionId="function:string-equal">
  >     <AttributeValue Datatype="....#string">Hello World</AttributeValue>
  >     <AttributeDesignator ....../>
  > </Apply>

  I know that there was one match to the value "Hello World" but
  I don't get back that value, I get a boolean value instead. If
  I have an add function that is inside of a floor function (for
  instance), I can't use anyOf to somehow make sure that bags
  with only one value get handled correctly by the functions,
  since I want to need to have the add function return a number,
  not a boolean. The comment in the change request was that anyOf
  can somehow be used to solve this, and my point is that it
  cannot.

  [Polar, responding to Seth] For the capability you allude to
  below you use the map function;

  <Apply FunctionId="function:map">
      <Function FunctionId="function:double-floor">
      <AttributeDesignator DataType="....#double" ....../>
  </Apply>
===================================================================
0134c: [Seth Proctor] Need Datatypes for each defined AttributeId
  e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00192.html

  STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4).  See RESOLUTION.
  SEE ALSO: CR#0150

  RESOLUTION: Each "standard attribute" should have a "standard
  datatype", since we proposed them for interoperability in the
  first place.  See
  http://lists.oasis-open.org/archives/xacml/200210/msg00290.html
  for attachment containing XACML_identifiers.doc, which is
  Simon's proposed list.  Simon has revised this to reflect all
  e-mail comments received, and sent the revised version to Tim
  for inclusion in v0.18f.doc

  CHANGE REQUEST:
  10.3.6 (Identifiers) doesn't list the type of any these
  attributes, nor does it give the required uses for them that it
  says implementors must follow. I realize this is transparent to
  a lot of the code, and only one of these is required to
  support, but it would still be helpful to know what type
  they're supposed to be (if there is a certain expected
  type). Later in the spec they're explained in a little more
  detail, but not enough to make the strong language in this
  section about correct implemention make sense.

  DISCUSSION:
  [Anne] Comments on Simon's proposed DataTypes:
  - subject-category:codebase: this should be anyURI (it is usually a URL)
  - subject-category:requesting-machine
    o we should have two requesting machine categories:
         requesting-machine-ip-address
         requesting-machine-dns-name
    o then both can be xsi:string
  - subject:subject-id: we can't say the "default is xsi:string" since
    DataType is required.
  - subject:subject-category: should be anyURI (see list in B.2 - they are
    all URNs)
  - subject:subject-id-qualifier: SAML says type not specified.  I suggest
    we let DataType specify the type or else say anyURI
  - subject:authentication-method: SAML uses anyURI, I suggest same
  - resource:resource-id: description says "This identifier
    indicates the entire URI of the resource."  I believe this
    should say "This identifier indicates the name of the
    resource."  I think we need to let DataType determine the type
    (it might be a string, it might be a URL, it might be a URN,
    etc.)
  - action:actionNamespace: should be anyURI to fit with SAML's use
==================================================================
0146: [Polar] CR 144: function "present" needs to be fixed.
  e-mail sent 22 Oct 2002 12:25:52 -0400 (EDT) 
  http://lists.oasis-open.org/archives/xacml/200210/msg00247.html
  http://lists.oasis-open.org/archives/xacml/200211/msg00032.html

  STATUS: UNRESOLVED (11/4).  Need semantics in QualifiedSubjectAttributeDesignator.
  SEE ALSO: CR#0092,CR#0154

  RESOLUTION: Make new XML elements in schema.  Remove them from
  Appendix A, put them in text description.  New proposal removes
  all the -must-be-present functions, since new XML attribute on
  attribute designator can do that.

  SPECIFIC RESOLUTION: See revised text in
  http://lists.oasis-open.org/archives/xacml/200210/msg00313.html
  (MSWord) or
  http://lists.oasis-open.org/archives/xacml/200210/msg00314.html
  (pdf)

  CHANGE REQUEST:
  The function "present" as we discussed yesterday in spec 18d is
  vague in whether it returns "false" or raises an
  "indeterminate" if the attribute is not present.

  DISCUSSION:
  .... (outdated discussion removed)
  My conclusion: Since attributes are retrieved by different
  schema elements, it seems most logical to make their
  "is-present" counterparts schema elements as well, using much
  of the same machinery already in place. It would be easy to add
  these as element of the AttributeDeignator/Selector/Type
  complex types we ALREADY have defined:

  So, I think a better approach would be to add the following
  elements to the schema with the semantics I proposed in the
  previous iterations.

  These elements would be element instances of the
  <AttributeDesignatorType>:

  ActionAttributeIsPresent      ActionAttributeMustBePresent
  ResourceAttributeIsPresent    ResourceAttributeMustBePresent
  EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent

  These elements would be element instances of the
  <SubjectAttributeDesignatorType>:

  SubjectAttributeIsPresent     SubjectAttributeMustBePresent

  These elements would be element instances of the
  <SubjectAttributeDesignatorWhereType>:

  These elements can be element instances of the
  <AttributeSelectorType>:

  AttributeIsPresent            AttributeMustBePresent

  [Simon] I think that <AttributeDesignator> and
  <AttributeSelector> elements with mustBePresent attribute will
  cover all cases:

  [Polar, responding to Simon]
  No, it won't. Thas is because I will not be able to write
  predicates about their presence, and only be able to get an
  "indeterminate" on requesting one.

  And also, again, in the Target, where these things appear, that
  attribute's semantics would complicate the idexing and
  retriveal of policies and rules etc etc etc.
=================================================================
0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy
  e-mail sent 29 Oct 2002 13:26:55 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200210/msg00293.html

  STATUS: NEEDS QUORUM.  RESOLVED (NQ 11/4).  Use xs:string" in both places.

  CHANGE REQUEST:
  The Issuer is an "xs:string" in the context, and "xs:anyURI" in
  the policy. (I am looking at 16j)
=================================================================
0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere
  e-mail sent 30 Oct 2002 15:22:32 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200210/msg00305.html

  STATUS: UNRESOLVED.  See partial RESOLUTION and OPEN ISSUE (NQ 11/4)
  SEE ALSO: CR#0092, CR#0146, CR#0152

  OPEN ISSUE:
  1) How to deal with missing attributes when evaluating
     a QualifiedSubjectAttributeDesignator.  If
     MustBePresent="true" on SubjectAttributeDesignator inside
     the new <SubjectQualifier> element, does this mean that
     every single <Subject> MUST contain an instance of that
     Attribute or else the QualifiedSubjectAttributeDesignator
     returns Indeterminate?  This is the same issue being
     addressed in CR#0092.
  2) If multiple <Subject> blocks match the
     QualifiedSubjectAttributeDesignator, then how does Policy
     know which returned attributes go with which <Subject>?

  RESOLUTION: 
  On 11/4, we agreed on the following changes to
  address the original Change Request.

  1) Replace all existing policy schema references to
     "SubjectAttributeDesignator" with "CategorizedSubjectAttributeDesignator"

  2) After doing 1), add the following fragment to the policy
     schema:

  <xs:element name="SubjectAttributeDesignator"
              type="xacml:AttributeDesignatorType"/>

  3) After doing 2), replace following policy schema fragment:

  <xs:element name="SubjectAttributeDesignatorWhere" type="xacml:SubjectAttributeDesignatorWhereType"/>
	<xs:complexType name="SubjectAttributeDesignatorWhereType">
		<xs:complexContent>
			<xs:extension base="xacml:AttributeDesignatorType">
				<xs:sequence>
					<xs:element ref="xacml:SubjectMatch" minOccurs="0" maxOccurs="unbounded"/>
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

  with

  <xs:element name="QualifiedSubjectAttributeDesignator"
              type="xacml:QualifiedSubjectAttributeDesignatorType"/>
  <xs:complexType name="QualifiedSubjectAttributeDesignatorType">
    <xs:complexContent>
      <xs:extension base="xacml:AttributeDesignatorType">
        <xs:sequence>
          <xs:element ref="xacml:SubjectQualifier"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="SubjectQualifier
              type="xacml:SubjectQualifierType"/>
  <xs:complexType name="SubjectQualifierType">
    <xs:sequence>
      <xs:choice>
        <xs:element ref="xacml:SubjectAttributeDesignator"/>
        <xs:element ref="xacml:AttributeSelector"/>
      <xs:choice>
      <xs:element ref="xacml:AttributeValue"/>
    </xs:sequence>
    <xs:attribute name="MatchId" type="xs:QName" use="required"/>
  </xs:complexType>

  CHANGE REQUEST:
  I think there's a problem with the schema involving the
  SubjectAttributeDesignatorWhere (or the proposed name
  SubjectQualifier, which I like more). It used to extend
  SubjectAttributeDesignatorType, but with the addition of the
  category element, it now only extends
  AttributeDesignatorType. It still contains, however, a list of
  SubjectMatchType, which in turn use
  SubjectAttributeDesignatorType as their designator.

  Shouldn't the match elements also extend
  AttributeDesignatorType and not SubjectAttributeDesignatorType
  in the SubjectQualifier? I think this needs a new match type
  that uses AttributeDesignator but is specified in the spec to
  look in the subject section of the request for all attributes.

  DISCUSSION:

  [Polar] In writing the stuff for the subjects, I've encountered
  a problem for the QualifiedSubjectAttributeDesignator. I think
  Seth was onto something in 0154 and 0155, but perhaps missed it
  a bit.

  The SubjectAttributeDesignator takes AttributeId, DataType,
  MustBePresent, and SubjectCategory. It restricts the lookup of
  the named subject attributes to the <Subject> matching the
  SubjectCategory.

  The QualifiedSubjectAttributeDesignator performs no such
  category restriction. It just takes AttributeId, DataType,
  MustBePresent, plus a bunch of <SubjectMatch>. The
  <SubjectMatch>s are supposed to be restricted to one subject.

  The only problem is that each SubjectMatch has an
  SubjectAttributeDesignator in it, which *ALREADY* restricts the
  look up to a particular subject matching the subject category.

  So, as a result, a QualifiedSubjectAttributeDesignator must
  have SubjectMatches all with the SAME subject category, or it
  wont retrieve anything. Also, having one SubjectMatch restricts
  it already to one Subject just by virtue of the category, which
  I think is not the case we want.


  [Polar] I suggest that we change the current
  SubjectAttributeDesignatorType to

    CategorizedSubjectAttributeDesignatorType

  and have

    CategorizedSubjectAttributeDesignator

  and keep the SubjectAttributeDesignator a simple instantiation
  of AttributeDesignatorType as it was before we added the
  SubjectCategory attribute.

  [Seth, responding to Polar] Is the intent to add a new AD type
  to those allowed in an Apply, and therefore also create a new
  MatchType? This might be overkill, though it could be useful.
=================================================================
0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere
  e-mail sent 30 Oct 2002 15:28:10 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200210/msg00306.html

  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See RESOLUTION.
  SEE ALSO: CR#0154

  RESOLUTION: See #0154.  The name of the sequence of elements
  inside the
  QualifiedSubjectAttributeDesignator/SubjectAttributeDesignatorWhere
  is changed from SubjectMatch to SubjectQualifier.

  CHANGE REQUEST:
  This is a followup to my last email on Match types in the
  SubjectQualifier ([xacml] Problem in
  SubjectQualifier/SubjectAttributeDesignatorWhere). If I'm
  right, and that structure needs to change, I would like to
  request that it not have the same name as the other match
  objects (ie, it should not be called something that looks like
  SubjectMatchType). While it is similar in structure to the
  other match types, the "match" elements used in the qualifer
  are symantically an entirely different thing, and should
  therefore be logically separated by using a different name, and
  should not be covered by the same explanitory text in the spec.
=============================================================================
0156: [Seth Proctor] ObligationType
  e-mail sent 31 Oct 2002 10:15:16 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200210/msg00312.html

  STATUS: UNRESOLVED

  CHANGE REQUEST:
  The ObligationType used to have a choice between an AttributeAssignment
  or an AttributeDesignator, but now you can only have the AA. As such, the
  xs:choice should probably be changed to xs:sequence, just to stay consistent
  with schema language.
=================================================================
0157: [Steve Hanna] Glitch in moving from decimal to double
  e-mail sent 31 Oct 2002 13:08:08 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200210/msg00315.html 

  STATUS: UNRESOLVED

  CHANGE REQUEST:
  I see that v18e reflects the TC's decision to move from
  xsi:decimal to xsi:double. I'm pleased with this decision,
  but I noticed a problem:

  The document cited as defining the arithmetic functions
  ([IBMSDA]) does not exist. Or at least the URL given in
  the document (http://www2.hursley.ibm.com/double/decarith.html)
  does not work. I suspect that this is the result of a
  global search and replace operation, changing decimal
  to double.

  I suggest that this reference be replaced with IEEE 754,
  which defines binary floating point arithmetic and is
  cited by XML Schema for that purpose.
=================================================================
0158: [Simon] [Schema Change] Redefine <AttributeValueType>
  raised during Subcommittee call on 11/4/02

  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4)

  RESOLUTION:
  1) In the context schema, replace following:

  <xs:element name="AttributeValue" type="xs:anyType"/>

  with:

  <xs:element name="AttributeValue"
              type="xacml-context:AttributeValueType"/>
  <xs:complexType name="AttributeValueType">
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>

  2) In the policy schema, replace following:

  <xs:complexType name="AttributeValueType">
    <xs:complexContent>
      <xs:extension base="xs:anyType">
        <xs:attribute name="DataType" type="xs:anyURI" use="required"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  with:

  <xs:complexType name="AttributeValueType">
    <xs:sequence>
      <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="DataType" type="xs:anyURI" use="required"/>
    <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>

  CHANGE REQUEST: Define <AttributeValueType> in both the
  policy and the context schemas in the same way that
  context:ResourceContent is now specified.

  RATIONALE: Validating parsers are happier with this way of
  specifying an "any" type>
=================================================================  
0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better
  e-mail sent 01 Nov 2002 11:56:332 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200211/msg00000.html

  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.

  CHANGE REQUEST:
  1. B.5 Subject attributes: Change initial paragraph from:

     "These identifiers indicate attributes of a subject.  At most
      one of each of these attributes is associated with each
      subject.  Each attribute associated with authentication
      relates to the same authentication event.

     To:

     "These identifiers indicate attributes of a subject.  When
      used, they SHALL appear within a <Subject> element of the
      Request Context.  They SHALL be accessed via a
      SubjectAttributeDesignator, a
      QualifiedSubjectAttributeDesignator, or an AttributeSelector
      pointing into a <Subject> element of the Request Context.

      At most one of each of these attributes is associated with
      each subject.  Each attribute associated with authentication
      included within a single <Subject> element relates to the
      same authentication event.

  2. B.6 Resource attributes: Add introductory sentence saying:

     "These identifiers indicate attributes of the resource being
      accessed.  When used, they SHALL appear within the <Resource>
      element of the Request Context.  They SHALL be accessed via a
      ResourceAttributeDesignator or an AttributeSelector pointing
      into the <Resource> element of the Request Context."

  3. B.7 Action attributes: Add introductory sentence saying:

     "These indentifiers indicate attributes of the resource being
      accessed.  When used, they SHALL appear within the <Action>
      element of the Request Context.  They SHALL be accessed via a
      ActionAttributeDesignator or an AttributeSelector pointing
      into the <Action> element of the Request Context."

  4. B.8 Environment attributes: Add introductory sentence saying:

     "These identifiers indicate attributes of the environment
      within which the request is to be evaluated.  When used, they
      SHALL appear within the <Resource> element of the Request
      Context.  They SHALL be accessed via an
      EnvironmentAttributeDesignator or an AttributeSelector
      pointing into the <Environment> element of the Request
      Context."

  RATIONALE: the way in which these attributes are to be used is
  not explicitly stated anywhere.  While the names imply a usage,
  it would be more clear to implementors if the usage were more
  explicit.
=================================================================  
0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better
  e-mail sent 01 Nov 2002 12:45:10 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200211/msg00001.html

  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.

  CHANGE REQUEST: (Example revised per Polar e-mail and 11/4 discussion)
  In Section A.3 Structured types, item 1., paragraph starting
  with "1, change second sentence from:

    "This requires the structured data, including its tags and
     attributes, to be identified and treated as an instance of
     the data-type xsi:string."

  To:

    "This requires the structured data <AttributeValue> to be
     given the DataType="xsi:string".  For example, a structured
     data type that is actually a ds:KeyInfo/KeyName would appear
     in the Context as:

     <AttributeValue
       DataType="DataType="http://www.w3.org/2001/XMLSchema-instance#string";>&lt;ds:KeyName&gt;jhibbert-key&lt;/ds:KeyName&gt;</AttributeValue>

  RATIONALE: Way#1 could be read as implying that the structured
  data type is automatically cast or converted to the type
  required by the function that references it.  We should be very
  clear that this does NOT occur.

  DISCUSSION:
  [Anne, responding to Polar]
   > Now, if you do not regard the data as a string, and you actually give
   > it a data type, i.e. extension to standard XACML, I wonder what happens
   > for the following problem.
   > 
   > Does the data within the attribute value have to be completely contained?
   > 
   > For example, if you have <ds:KeyName>jhibberi-key</ds:KeyName> where is
   > the "ds:" name space defined? (In the begining of the context? of which it
   > cannot be guarranteed to be there) Or in the attribute value?

  The ds: name space must be defined in the beginning of the
  context if "ds:" is used in an XML fragment.  If it is not
  defined there, then there will be an error parsing the XML
  context.
=================================================================  
0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn"
  e-mail sent 01 Nov 2002 12:52:45 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200211/msg00002.html

  STATUS: NEEDS QUORUM.  APPROVED (NQ 11/4).  See CHANGE REQUEST.

  CHANGE REQUEST:
  In policy schema, <xs:complexType name="ObligationType">,
  change <xs:attribute name="FulfilOn" to <xs:attribute
  name="FulfillOn"

  RATIONALE: Spec uses "FulfillOn", and we decided in a TC
  meeting to use that spelling.  Schema just has not been brought
  into agreement yet.
==================================================================
0162: [Polar] [Schema/Text Change] Subjects
  e-mail sent 04 Nov 2002 16:43:06 -0500 (EST)
  http://lists.oasis-open.org/archives/xacml/200211/msg00032.html
  http://lists.oasis-open.org/archives/xacml/200211/msg00037.html (schema)

  STATUS: UNRESOLVED.

  CHANGE REQUEST:
  Using QualifiedSubjectAttributeDesignators where there are
  multiple <Subject> elements, particularly where multiple
  <Subject> elements have the same subject-category means you may
  get back multiple attribute values without knowing which
  <Subject> element they came from.

  RESOLUTION#1:
  Make the subjects (i.e. lists of attributes) unique to the
  category, and use the present SubjectAttributeDesignator (with
  the SubjectCategory part) and get rid of the
  SubjectAttributeDesignatorWhere. That's simple and I think
  everybody can get their brains wrapped around that.

  RESOLUTION#2:
  See
     http://lists.oasis-open.org/archives/xacml/200211/msg00066.html
  which contains revised Section 5.
  
  General description of proposed resolution:

  Eliminate the SubjectCategory from the
  SubjectAttributeDesignator and add the SubjectQualifiers to the
  SubjectAttributeDesignator.

  A SubjectQualifier extends a AttributeDesignator with the
  following attributes "MatchId" and a "AttributeValue" element.

  This approach allows you to qualify the SubjectMatch in the
  target to any category or any other attribute. The only thing
  that remains a problem for targeting is the MustBePresent, as
  before.

  Next extend QualifiedSubjectAttributeDesignator
  SubjectAttributeDesignator with a "FromSubjects" attribute of
  which its default value is "single-subject", as opposed to
  "multiple-subjects".

  Only QualifiedSubjectAttributeDesignators are allowed to be
  Expressions.  If the FromSubjects attribute is set to
  single-subject and multiple subjects match, the expression
  raises an indeterminate.

  QualifiedSubjectAttributeIsPresent extends
  SubjecAttributeDesignator with a "MustBeSingleSubject"
  attribute. If MustBeSingleSubject is set to "true" and the
  qualifiers select zero or more than one subject, then the
  answer is false.  Otherwise, it returns the true if the
  attribute is within that selected subject. A true result with
  MustBeSingleSubject set to true means that the attribute is
  present and a QualfiedSubjectATtributeDesignator with
  FromSubjects=single-subject will not raise an indeterminate.

  DISCUSSION:
  [Anne] In a <Target>, we currently allow one or more
  SubjectMatch elements, each of which contains a MatchId, a
  SubjectAttributeDesignator/AttributeSelector and an
  AttributeValue.

  Under your proposal, I think "Example" [deleted, since it was
  actually not valid] below is a valid <Target>, meaning: there
  must be at least one <Subject> element in the Request where all
  of the following are true:

    by first SubjectMatch:
     the xxx AttributeId has a value of "ghi"
     the yyy AttributeId has a value of "abc"
     the zzz AttributeId has a value of "def"
    by second SubjectMatch:
     the aaa AttributeId has a value of "qrs"
     the bbb AttributeId has a value of "jkl"
     the ccc Attributeid has a value of "mno"

  What do we gain over having multiple <SubjectMatch> elements,
  each with a single AttributeDesignator and value to be matched?

  [Polar, responding to Anne] I think the answer to your
  question, is that Multiple Subject matches must match any
  subject and they are not related to each other. That is one
  SubjectMatch has nothing to do with the subjects matched in
  another.

  The SubjectMatch with a SubjectAttributeDesignator matches on a
  restricted set of subjects.

  [Polar, responding to Simon]
  > I'm trying to understand your proposal.  what you do is:

  > attr-desig-type(attrid, data-type, issuer, must-be-present)
  >     subject-qualifier(match-id, attr-value)
  >     subj-attr-desig-type(0...many subj-qualifier)
  >         qualified-subj-attr-desig(from-subjects)

  Yes. (I think)

  > then qualified-subj-attr-desig is used in the subject-match in the target
  > and in the apply element.
  >
  > it looks like subj-attr-desig-type is not used by itself.

  Correct. It's only used for extenstion to
  QualifiedSubjectAttributeDesignator and
  QualfiiedSubjectAttributeDesignatorIsPresent.

  > subject expression in the target is now quite complicated.

  You still had to match on a subject category attribute. That is
  no different on matching on any other named attribute,
  really. The only thing, is now that you may have more
  qualifying it in an AND, of which I don't think is that bad.
  (i.e match me all subjects that have weight = 100 with
  subject-category = access-subject, and role = doctor.

  Indexing can still prevail.

  [Polar, responding to Anne]
  > But all matches within a single <Target><Subject> must pertain to
  > one Request <Subject>.  If you want to specify subject matches
  > that are not related to that <Subject>, then you use another
  > <Subject> element in your <Target>.

  Right, I forgot that.  Anyway, that suffers from the same
  misleading problem, doesn't it? It means the "subjects" for
  which the subject matches apply.

  [Polar, responding to Simon]

  > We have an open issue with subject designators that we want
  > to solve asap.  There is a proposal from Polar, but I think
  > it is too complicated for quick adoption.
  >
  > My proposal:
  > a) Quick solution to vote on thrs: Keep current
  >    subject-attribute-designator element with subject-category
  >    attribute and use it in the target and apply
  >    elements. Drop subject-attr-desig-where. I think it will
  >    cover 95% of all cases.

  I wouldn't mind this, except for having multiple subjects for a
  category!  It just balls everything up. I cannot tell which
  subject my attributes are comming from. That really bothers me.

  I think we have screwed this whole thing up with multiple
  subjects requirement and not understanding the ramifications of
  the queries on them.

  In my latest proposal, I've added complex attributes to the
  elements to pop up indeterminates in the case where you get
  multiple subjects matched.  I don't really like that
  solution. But I made the analogous IsPresent operator use
  another attribute so that it returns false if the Qualifiers
  select more than one subject. This also complicates the
  SubjectMatch in that it has to throw an indeterminate when the
  designator qualifies multiple subjects. Yuck! I hate it.

  > b) Work out alternative proposal and delay voting until it is
  >    resolved 

  I think a better more workable solution would be to make the
  subjects (i.e. lists of attributes) unique to the category, and
  use the present SubjectAttributeDesignator (with the
  SubjectCategory part) and get rid of the
  SubjectAttributeDesignatorWhere. That's simple and I think
  everybody can get their brains wrapped around that.

  I think this approach will solve 95% of the simple cases as
  well. And let's wait to 1.1 or 2.0 to get multiple subjects
  down. It's already bad enough with multiple subject
  categories. Geeezzz!

  [Simon, for RESOLUTION#1]
  +1
  I would support [Polar's "better more workable solution above]

  [Anne, for RESOLUTION#1]
  > I think a better more workable solution would be to make the subjects
  > (i.e. lists of attributes) unique to the category, and use the present
  > SubjectAttributeDesignator (with the SubjectCategory part)  and get rid of
  > the SubjectAttributeDesignatorWhere. That's simple and I think everybody
  > can get their brains wrapped around that.

  I can live with this.  What we lose is the ability to associate
  attribute values with the identities and authentication methods
  under which those attributes were issued.  We can continue to try
  to improve this for 1.1 or 2.0.  I really think we are going to
  need some serious thought to solve the problems raised by
  SADWhere, and I would rather have a good solution than a complex,
  understudied, possibly unworkable one.

  [Carlisle, for RESOLUTION#1]
  This is my vote as well:  something workable in most cases for
  1.0; something fancier for 1.1 / 2.0.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC