xacml — archive

[Anne Anderson <anne.anderson@sun.com>]

Attached is the list of Change Requests as of 3pm Wed. afternoon (EDT). I have included the substance of all the comments for the "active" issues, so this is a "one stop shop" document for our meeting tomorrow (except for the ton of mail that will come in right after I post this :-). 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 2 Author: Anne Anderson Version: 1.8, 02/10/02 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests2.txt This version contains all Change Requests not reflected in v17.0 of the specification (i.e. received after the TC meeting on 26 Sept 2002. For earlier Change Requests (all disposed of by 26 Sept 2002) see the following e-mail in the archive: http://lists.oasis-open.org/archives/xacml/200209/msg00185.html or reference the mail titled "[xacml] Updated Change Request list", from Anne Anderson, 26 Sep 2002. Contains all e-mail up to and including archive msg msg00203.html ACTION ITEMS ============ None LEGEND ====== NQ=no quorum; official vote required Q=quorum SUMMARY ======= 0064. [Michiharu] <AttributeSelector> Text change request STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30) 0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13 STATUS: APPROVED (NQ 9/30) with addition of footnote text. 0066. [Simon] change request: namespaces in xpath expressions STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved. 0067. [Simon] change request: resource content STATUS: APPROVED (NQ 9/30). Proposal 1 only. 0068. [Simon] change request: subject-attribute-designator and subjectcategory STATUS: Discussed 9/30. No resolution. Anne in favor. 0069. [Simon] change request: xacml context attributes and data types STATUS: Discussed 9/30. See [9/30] below. Feedback requested. 0070. [Michiharu] resource:scope attribute missing STATUS: APPROVED (NQ 9/30) 0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name STATUS: APPROVED (NQ 9/30) 0072. [Simon] subject attribute designators STATUS: e-mail dated Tue,01 Oct 2002 0073. [John Howard] Comparing KeyInfos STATUS: e-mail dated 02 Oct 2002, forwarded by Anne DETAILS ======= 0064. [Michiharu] <AttributeSelector> Text change request http://lists.oasis-open.org/archives/xacml/200209/msg00179.html STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30) AttributeSelector, Page 49 <AttributeSelector> [required] MAY be used to identify one or more values in the <Subject> element of <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Subject> element of the <xacml-context:Request> element. ==> <AttributeSelector> [optional] Attribute selector using XPath expression. It MUST contain a legal xpath expression over the <xacml-context:Request> element. This operator returns a bag of string data or a single primitive value. In case of XPath 1.0, an evaluation value of the XPath expression is either a node set, string value, numeric value, and boolean value. When node set is returned, each node may consist of children nodes (structured node). Then each node is converted into a string data by applying a string function defined in XPath 1.0 specification. Then this operator returns a bag of string values. When either string, numeric or boolean value is returned, this operator returns a single primitive value of xs:string, xs:decimal, and xs:boolean type, respectively. When this element is specified, the policy MUST define the version of the XPath specification using <XPathVersion> element. When an xpath expression has one or more namespace prefix, they are resolved using XPath namespace and prefix information specified in the <XPathNamespace> element below this operator. If no such element is specified, then an <XPathNamespace> element in <PolicyDefaults> element in the parent <Policy> (or <PolicySet>) element is used. [Polar] <AttributeSelector> AttributeSelector using an XPATH expression. The AttributeSelector's "RequestContextPath" XML attribute shall contain a legal XPATH expression over the <xacml-context:Request> element. The selector element evaluates to a bag of a single primitive value that is implied by the type system, i.e. the function application in which the selector appears. In case of using XPATH 1.0, the value of the XPATH expression is either a node-set, string value, numeric value, or boolean value. If the XPATH 1.0 expression evaluates to a node-set, each node may consist of a string, numeric, boolean value, or a child node (ie. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in XPATH 1.0 specification resulting a sequence of string data. In the single string, numeric, or boolean value case, the value is converted to string data by applying the string function defined in XPATH 1.0 specification resulting in a sequence of one string data element. In XPATH 2.0, the result of the XPATH expression is always a sequence of nodes. In this case, each node is logically converted to a string using the aforementioned string function resulting in a sequence of string data. The resulting sequence of string data is converted to a bag of primitive values that is implied by the type system. [Polar, quoting Michiharu] > The sentence you provide is basically fine. > > [1] > in XPATH 1.0 specification resulting in a sequence of one > string data element. > ==> > in XPATH 1.0 specification resulting in a bag of one string > data element. Actually, I used "sequence" to unify both the XPATH 1.0 and 2.0 descriptions. Then logically convert the "sequence of string data" to a bag of primitive values. > > [2] > Since XPath 2.0 returns either a sequence or the error > value, we should say that "the result of the XPATH > expression is a sequence of items (item is an atomic value > or a node) or the error value. When the error value is > returned, the PDP SHOULD return Indeterminate." OKay. [Michiharu] OK. In case of XPath 2.0, "xf:string accessor" is better than "aforementioned string function". [New Text approved 9/30/02] <AttributeSelector> AttributeSelector using an XPATH expression. The AttributeSelector's "RequestContextPath" XML attribute shall contain a legal XPATH expression over the <xacml-context:Request> element. The selector element evaluates to a bag of a single primitive value that is implied by the type system, i.e. the function application in which the selector appears. In the case of using XPATH 1.0, the value of the XPATH expression is either a node-set, string value, numeric value, or boolean value. If the XPATH 1.0 expression evaluates to a node-set, each node may consist of a string, numeric, boolean value, or a child node (ie. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in the XPATH 1.0 specification, resulting a sequence of string data. In the single string, numeric, or boolean value case, the value is converted to string data by applying the "string" function defined in the XPATH 1.0 specification, resulting in a sequence of one string data element. In XPATH 2.0, the result of the XPATH expression is a sequence of items (where an item is an atomic value or a node) or the error value. When the error value is returned, the PDP SHOULD return "Indeterminate". Otherwise, each node is logically converted to a string using the xf:string accessor function, resulting in a sequence of string data. The resulting sequence of string data is converted to a bag of primitive values that is implied by the type system. 0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13 http://lists.oasis-open.org/archives/xacml/200209/msg00186.html STATUS: APPROVED (NQ 9/30) with addition of footnote text. The descriptions for the functions x500Name-equal and x500Name-match in XACML_Functions.doc v13 are mixed up. In particular, the "x500Name-match" description is actually the "x500Name-equal" description. Here are the correct descriptions: o x500Name-equal This function shall take two arguments of "xacml:x500Name" and shall return an "xs:boolean". It shall return true if and only if each Relative Distinguished Name (RDN) in the two arguments matches. Two RDNs match if and only if the result of the following operations is true.[*] First, normalize the two arguments according to IETF RFC 2253 "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names". Second, if any RDN contains multiple attributeTypeAndValue pairs, re-order the Attribute ValuePairs in that RDN in ascending order when compared as octet strings (described in ITU-T Rec. X.690 (1997 E) Section 11.6 "Set-of components"). Finally, compare RDNs using the rules in IETF RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) PRofile", Section 4.2.1.4 "Issuer". [*] ITU-T Rec. X.520 contains rules for matching X500 names, but these are very complex and require knowledge of the syntax of various AttributeTypes. IETF RFC 3280 contains simplified matching rules that the XACML x500Name-equal function uses. o x500Name-match This function shall take two arguments of "xacml:x500Name" and shall return an "xs:boolean". It shall return true if and only the first argument matches some terminal sequence of RDNs from the second argument when compared using x500Name-equal. 0066. [Simon] change request: namespaces in xpath expressions http://lists.oasis-open.org/archives/xacml/200209/msg00190.html STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved. There are several instances in the policy schema where we pass xpath expressions as arguments. 1. In the case of <xacml:AttributeSelector> element RequestContextPath attribute contains xpath expression that selects xacml attribute value from the context. 2. When xpath functions are used in the target, the value to match again is xpath expression. 3. When xpath functions are used in conditions they take xpath expressions as arguments. All examples are from section 4.2 For the attribute-selector we use XPathNamespace element that maps namespace uri to namespace prefix (essentially duplicating standard xml namespace declaration) AttributeSelector: <AttributeSelector RequestContextPath= "//ctx:RequestContext/md:record/md:patient/md:policyNumber"> <XPathNamespace NamespaceURI="urn:names:tc:xacml:1.0:context" Prefix="ctx"/> <XPathNamespace NamespaceURI=" http://www.medico.com/schemas/record.xsd" ; Prefix="md"/> </AttributeSelector> For other uses of xpath functions we do not have special provisions for namespace mapping. Here is how xpath expression is used in the target to match request: <ResourceMatch matchId="function:xpath-match"> <ResourceAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:resource:xpath"/> <AttributeValue>/md:record</AttributeValue> </ResourceMatch> In this case we rely on standard xml namespace declaration for the md prefix. To summarise: we use two methods to deal with the same problem: one is standard and one is not. Proposal: 1. Use standard xml namespace declarations mechanism in both cases and drop <XPathNamespace> element. 2. Change RequestContextType attribute of AttributeSelector to xs:string (it is currently xs:anyURI). [Michiharu] I understand your intention but I am not sure whether or not using standard XML namespace (your first proposal) is really good for our case. My opinion is that standard XML namespace (you mean xmlns:md =" http://www .... record.xsd", right?) should primarily mean the namespace for element name of the policy itself. In other words, XACML policy may include other namespace (currently seems not but actually we had when SAML schema fragment was used in our policy). I think xmlns should be used for that case. Since we need to determine the namespace for the value of the policy (not element name nor attribute name), it seems reasonable to use application-specific namespace designator (XPathNamespace) currently we have. How do you think? [Simon] You are correct, xmlns decl is used for elements and we have data. Our first problem is that we do not cover all cases with XPathNamespace element. Also, declaring XPathNamespace in the PolicyDefaults is equivalent in my opinion to declare namespace prefix on the Policy itself. So I'd like to use xmlns decl, although it's usage is applied to data. 0067. [Simon] change request: resource content http://lists.oasis-open.org/archives/xacml/200209/msg00191.html STATUS: APPROVED (NQ 9/30). Proposal 1 only. <xacml-context:Resource> element has <xacml-context:ResourceContent> child. If resource content is relevant in access decision it is placed as a child of <ResourceContent> element. Currently, the only way to access <ResourceContent> and it's children elements is with <xacml:AttributeSelector>, support for which is optional. There is no way to access this data with <xacml:ResourceAttributeDesignator>. Proposal 1: Introduce resource attribute identifier: "urn:oasis:names:tc:xacml:1.0:resource:resource-content" that will address <ResourceContent> element. In this case, both <ResourceContent> and identifier refer to the same entity. No schema change required. Proposal 2: Drop <ResourceContent> element and introduce resource identifier as above. The xpath expressions in the <xacml:AttributeSelector> will be taken over this resource attribute: <AttributeSelector RequestContextPath= "//ctx:Request/ctx:Resource/ ctx:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:resource:resource-content']/*"/> In both cases (1) and (2) we can access content with resource-attribute-designator: <ResourceAttributeDesignator AttributeId="urn:oasis:names:xacml:1.0:resource:resource-content"/> [Michiharu] I am ok with your first proposal but I am not clear on the second one. The intention of having a ResourceContent element in XACML Request Context is that it must allow any arbitrary XML fragment below ResourceContent element. That's why the schema allows any structure. If you remove the ResourceContent and place the arbitrary XML fragment below Attribute element instead, you will need another changes on schema, for example to allow any elements below Attribute element or to introduce a new elements like ResourceContent. [Simon] Ok, than we can declare an attribute identifier that will point to the content (alt 1). 0068. [Simon] change request: subject-attribute-designator and subjectcategory http://lists.oasis-open.org/archives/xacml/200209/msg00192.html STATUS: Discussed 9/30. No resolution. Anne in favor. xacml request context supports multiple <xacml-context:Subject> elements. Each <xacml-context:Subject> element is tagged with the subject-category, such as: access-subject, codesource, etc. Subject category name is unique, ie there is no two <xacml-context:Subject> elements in the request context with the same value of subject-category attribute. <xacml:Subject> element in the policy allows us to specify multiple subject matches at the same time: sm1 'and' sm2 'and' sm3 etc. Syntactically, context subject attribute is selected with <xacml:SubjectAttributeDesignator> element that names attribute-id and issuer. Very often all subject attributes must be selected from the same subject block. Proposal: Extend <xacml:SubjectAttributeDesignator> with optional SubjectCategory attribute: <xs:complexType name="SubjectAttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> <xs:attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new attribute </xs:complexType> [Polar] I thought the purpose of the SubjectAttributeDesignatorWhere was to get all matches from the same subject, of which subject-category was one of the attributes you match on. I think we worked this out quite well, and cuts down on the machinery needed to just select mere attributes from a subject. [9/30 discussion] Polar's objection does not apply to Simon's case, since SubjectAttributeDesignatorWhere can not be used in a Target. Anne is in favor of Simon's proposal, but the group feels more input is needed. 0069. [Simon] change request: xacml context attributes and data types http://lists.oasis-open.org/archives/xacml/200209/msg00193.html STATUS: Discussed 9/30. See [9/30] below. Feedback requested. Currently <xacml-context:Attribute> element allows DataType attribute. Rationale for keeping DataType attribute in the <xacml-context:Attribute> element was that it can sometimes be helpful, such as specifiying subject-id format, like subject-id="cn=simon", data-type="x500-name" But this information is redundant, because subject-id attribute will be passed to the specific function that expects arguments of certain type. For example, if subject-id is passed to the x500Name-equal function it expects it's arguments to be in x500 name format. So data type does not add value here. Another problem is that we can not access DataType attribute with AttributeDesignator. Proposal: remove DataType attribute from the <xacml-context:Attribute>. [Anne] But, as discussed on yesterday's call, a <Subject> may have more than one subject-id attribute. For example, one may give the rfc822Name under which the subject authenticated, and another may give the x500Name. The datatype is required to allow the AttributeDesignator to select the instance of the attribute that has the correct datatype for the function in which the designator occurs. [Polar] I agree with removing the dataType attribute from the xacml-context:Attribute. However, the implications are this: If you have an Attribute of "subject-id" and its value is: <AttributeValue>CN=Simon Godik, O=OverXeer, OU=Research</AttributeValue> What does the designator: <SubjectMatch MatchId="function:rfc822Name-equal"> <SubjectAttributeDesignator AttributeId="subject-id"/> <AttributeValue>simon@godik.com</AttributeValue> </SubjectMatch> evaluate to? Does it evaluate to "indeterminate" because the formal type of rfc822Name-equal is xacml:rfc822Name -> xacml:rfc822Name -> Bool and the attribute value is an invalid representation of an rfc822Name. Or does it evaluate to "false"? The question in the context of its application, the <SubjectAttributeDesignator Attribute="subject-id"> shall return a bag of "rfc822Name", which means that every "subject-id" attribute must have a parseable rfc822Name representation as a value. So, does the designator return "indeterminate" because not *all* values under "subject-id" are valid string representations of rfc822Name? Or does it return a bag of rfc822Names of *only* the values under "subject-id" that do have valid string representations of rfc822Names? In the example above for the latter case, this designator would return an empty bag. [Polar, responding to Anne] Right, if the dataType attribute exists, if you are looking for attributes of a particular datatype, of which our XACML strong type system will infer, you can pick them out of the context by the dataType attribute. It can be optional, however, as I pointed out in my last email, you have to decide on what to do with the designator if the AttributeValue isn't a valid parseable representation of the data type named in the dataType attribute. [Bill] i suggest that this has to evaluate to FALSE. INDETERMINATE implies that the value is out of scope of the data set. while it may be argued that this is true at the philosophical level, i don't think it is consistent with how we are handling similar issues--what happens if a PEP requests to 'toad the wet sprocket' (resource unknown, action unknown)? this is consistent with my current assumptions that these values will be evaluated as [right-to-left] string comparisons. if that isn't the case, then i would like to hear the reasoning for requiring the logic necessary to differentiate between the two at evaluation time (explicit vs. implicit run-time type validation) [Simon, responding to Anne] If this is the case we should extend attribute designator to specify data type of the attribute to be selected. [9/30] In the meeting on 9/30, the following issues were outlined: 1. Need to be able to select attributes based on datatype. Example: Policy writer wants to indicate "This policy applies to all requests containing a <Subject> that has an x500Name of "cn=Anne, o=Sun, c=US". The policy Target using the 16i schema would contain: <Subjects> <Subject> <SubjectMatch MatchId="function:x500Name-equal"> <SubjectAttributeDesignator AttributeId="subject:subject-category"/> <AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue> </SubjectMatch> </Subject> </Subjects> But, assume a given <Subject> has authenticated with both an rfc822Name and an x500Name. Then the Request will look as follows: <Subject> <Attribute AttributeId="subject:subject-category" DataType="x500Name"> <AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue> </Attribute> <Attribute AttributeId="subject:subject-category" DataType="rfc822Name"> <AttributeValue>anne@Sun.COM</AttributeValue> </Attribute> </Subject> The policy should be applicable to this Request (I think), but the SubjectAttributeDesignator will match both Attributes in the Request, and one of them will be of type "rfc822Name". Not only will the result be a bag (which can't be passed to x500Name-equal), but there will be a conversion error in attempting to convert the rfc822Name to an x500Name. 2. Where are values converted to internal representations that are typed? Does this occur when the - Context AttributeValue is parsed? - AttributeDesignator is parsed? - SubjectMatch MatchId function is evaluated? We need feedback from people who are doing actual implementations on this. 3. We agreed that, if a function is passed a value that is the wrong type, that the result is "Indeterminate", NOT "False". So we need a way for the policy writer to select only the values that are (at least are intended to be) of the right type. 4. We all agreed that the PDP can not rely on the PEP or the PAP to specify correct datatypes for values. But a datatype specification could be used to indicate intent. [Polar] So we are back to putting the x500Name data type back in the attribute designator? Geez, I thought the vodka was making my head spin! [Seth Proctor] I am (somewhat) concerned about the choice to remove type information from the AttributeValue type in the Policy schema. I understand that the Function listed in the AttributeValue tells us what types are allowed, but there are two problems I see here. First, It is significantly more work for a programmer to support this method for finding the attribute's type, and it requires an API that is more complex (for extending the engine to support custom functions). This is a small issue, but it's one to consider when making a language change. The second problem I see is more serious. While the function gives us the type the attribute is expected to be, it doesn't tell us what the attribute's type actually is. If someone builds a policy, and puts in an integer value (for instance) as an input for a function that expects a string, the attribute will parse fine, but will not be used in the way that was intended for the attribute value. Obviously this is a simple example where it might not be such a problem, but with custom datatypes this could be more serious. There is no way to check that the attribute type being used is the correct one. Including the attribute type in the AttributeValue object may be redundant from a language point of view, but it provides (in my opinion) a valuable reality-check to make sure that the policy isn't being evaluated in a manner that the policy author didn't intend. In the case of the Attribute type in the Context schema, the problem is compounded. First, the implementation is harder, since when you're parsing the Request object you can't parse any of the attribute types, since you don't know what type they are until you start processing the policy and find what functions are being used. Not only is this harder, but it's (arguably) less effecient. Second, because you can't parse the attribute values until you consider them in the scope of a function, you could end up with designators that select the same attributes as inputs into functions that take different values. Drawing from the example above, what happens if a policy wants to interpret the same attribute as a String, an Integer, and some custom type? Is this an error, or should this be allowed? I suspect that all Requests will be formed with attributes of known and intended values, so I think this is a real problem. Last, because the Attributes aren't being included in the Request in the scope of a Function, the requestor has no idea how the attribute will be used in the policy, and so trying to guess at the value based on the function's types seems very dangerious to me. I would suggest that the type field in the Attribute type be made manditory. It may not seem as pretty in the language, but it heads off a lot of ambiguity without adding almost any overhead to the language (or making it any harder to form a Request), and that seems like a very worthwhile tradeoff to me. I would welcome any discussion on this topic with those of you on the list. I would like to see a final version of the language soon, so please don't take any of this as an attempt to slow things down. I have backed off on other issues with Anne that I didn't think were worth taking the time to address, but I feel this issue is pretty important to sort out. Including the types of Attibutes and AttributeValues is a seriously small piece of the schema, but it can have significant effects on implementation and interpretation. [Daniel] I would agree with his suggestion of keeping the dataType. I would also like to point out his concern that "it requires an API that is more complex (for extending the engine to support custom functions)" I have noticed the same issue. It is even more pronounced with the "higher-order" functions, with their current syntax. BTW - was there any discussion on MIchiharu's proposal on their extensibility? 0070. [Michiharu] resource:scope attribute missing STATUS: APPROVED (NQ 9/30) The <prefix>:resource:scope attribute and its values, as described in 7.2 Hierarchical resources, is not included in Appendix B or in the Conformance Section. These should be included. [Appendix B: add to list:] This identifier indicates the scope of the resource, as described in Section 7.2 Hierarchical resources. urn:oasis:names:tc:xacml:1.0:resource:scope The allowed value for this attribute is of type xs:string, and is either "Immediate", "Children", or "Descendants". [Conformance Section, Attributes, add to list] urn:oasis:names:tc:xacml:1.0:resource:scope O 0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name STATUS: APPROVED (NQ 9/30) [Section B, DataTypes, add after] urn:oasis:names:tc:xacml:1.0:datatype:x500Name An x500Name contains an ITU-T Rec. X.520 Distinguished Name. The valid syntax for such a name is described in IETF RFC 2253 "Lightweight Directory Access Protocol(v3): UTF-8 String Representation of Distinguished Names". urn:oasis:names:tc:xacml:1.0:datatype:rfc822Name An rfc822Name contains an "e-mail name". The valid syntax for such a name is described in IETF RFC 2821, Section 4.1.2 Command Argument Syntax, under the term "Mailbox". 0072. [Simon] subject attribute designators http://lists.oasis-open.org/archives/xacml/200210/msg00001.html STATUS: e-mail dated Tue,01 Oct 2002 Xacml request context allows for multiple subjects. Each subject block is identified with the subject-category. Subject-category identifies different 'actors': access-subject, codesource, etc. Category of 'access-subject' is requestor's identity. There are use cases, such as 'integrated login' where multiple auth mechanisms are integrated. Sun solves this with 'pluggable auth module' framework (pam). Pam allows for multiple authentication protocols to be configured per application. This shows that xacml context may contain multiple subject blocks with the same category of 'access-subject': separate block per authentication protocol. Subject blocks are accessed with subject-attribute-designators. Assumpsion: subject block is uniquely addressed by subject-category and authentication protocol. Proposal. Drop DataType attribue of the <xacml-context:AttributeType>. Extend xacml:subject-attribute-designator with subject-category, and protocol attributes: <complexType name SubjectAttributeDesignatorType> <attribute name="AttributeId" type="xs:string" use="required"/> <attribute name="Issuer" type="xs:anyURI" use="optional"/> <attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new <attribute name="Protocol" type="xs:anyURI" use="optional"/> <-- new </complexType> example 1.1 - match 'group' attribute of a subject authenticated with kerberos: subject-match match-id="string-equal" subj-attr-desig attr-id="group" issuer="some-issuer" subj-cat="access-subject" protocol="kerb" attr-value admin example 1.2 - match 'subject-id' attribute of a subject authenticated with kerb: subject-match match-id="rfc822Name-match" subj-attr-desig attr-id="subject-id" subj-cat="access-subject" protocol="kerb" attr-value bart@simpson.com Note that in example 1.2 subject block is identified by the protocol (kerb), not by the name format. [Polar] This is where we get into complex principals that are subject to the requests. If you allow more than one for the subject category, You end up with the same problem with subject-category="access-subject", whether you have it as an Attribute or not, because your designator will return values for each attribute type requested, and you will not be able to tell which one they are from. I thought, we were saying that for now, i.e. 1.0, there is only one access-subject, denoted by the subject-category attribute. True with the PAM you may have several IDs for a subject based on different protocols. However, on the target side, when a request is made, you will generally only have one authentication protocol used, and therefore only one id for the access-subject. Please, let's keep this simple enough to provide acess-control for simple subjects on simple resources at the target. I don't know if this is happed, but I think we should stay with the model that: 1 "subject-category" is an Subject Attribute. 2. Only one Subject per "subject-category" in the RequestContext. However, we can add "authentication-mechanism" as attribute, as well as "authentication-protocol". Note; the two may be different, or not implied by one or the other. [Simon] Polar, I do agree with you that unique subj-category is the simpliest case. And it was my understanding for some time. We have to decide if the 'integrated login' that is solved by sun with pam is a requirement that must be met in xacml 1.0. Pam specifically calls out a use case when user must be authenticated with more than one protocol. I would support postponing 'integrated login' till the next version, but in the mean time I wanted to have concrete proposal how to deal with it if we have to. 0073. [John Howard] Comparing KeyInfos http://lists.oasis-open.org/archives/xacml/200210/msg00003.html STATUS: e-mail dated 02 Oct 2002, forwarded by Anne In a couple of the conformance tests (IIB016, 11B017) there is a requirement to compare KeyInfos. The comparison is performed as a string-match even though the data type is KeyInfo. As KeyInfos can be compared in a number of ways the string-match would appear inadequate. e.g. In the simple case <ds:KeyInfo> <ds:KeyName>jhibbert-key</ds:KeyName> </ds:KeyInfo> would not match <ds:KeyInfo> <ds:KeyName>jhibbert-key</ds:KeyName> <ds:KeyValue>....</ds:KeyValue> </ds:KeyInfo> Although the KeyInfos are the same. Is there a need for a keyinfo-match function or is there a more generic object-match that would match based on the data type and therefore be completely extendable.