[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Committee Specification vote/Updated Change Requests
I'll attend. Simon ----- Original Message ----- From: "Anne Anderson" <Anne.Anderson@Sun.com> To: "XACML TC" <xacml@lists.oasis-open.org> 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: 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.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. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC