I'll attend.
Simon
----- Original Message -----
From: "Anne Anderson" <>
To: "XACML TC" <>
Sent: Tuesday, November 05, 2002 9:12 AM
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:
> 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.ChangeReq
uests5.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"><ds
:KeyName>jhibbert-key</ds:KeyName></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.
>
>
>
>
