[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] the saml token profile depends on non-global attributes in key identifier/wsse schema does not support keyIdentifier element extensibility
The have historically been problems mixing content type. This is currently a simple type and it sounds like SAML needs a complex type. I think that in this case it might be advantageous to separate them. Maybe we should think about a KeyReference in V1.1 which SAML and others could use to specify more structured types of references? Thoughts? -----Original Message----- From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] Sent: Wednesday, January 21, 2004 1:37 PM To: Chris Kaler Cc: wss@lists.oasis-open.org; Levinson, Richard Subject: Re: [wss] the saml token profile depends on non-global attributes in key identifier/wsse schema does not support keyIdentifier element extensibility Chris Kaler wrote: >Sorry, I mis-read as attributes. > >For this case why not just define a new SAMLKeyIdentifier element which >has the specific content you need and parallel what DSig did for X.509? > > I think that would work, but I would prefer to be able to work within the existing alternatives of direct reference and key identifier. Perhaps the element you suggest could extend keyIdentifier, although I have seen recommendations that advocate that extensibility by derivation be applied to abstract as apposed to concrete types. What do you think ofthe following * A key identifier reference - a generic element (i.e. <wsse:KeyIdentifier>) that conveys a security token identifier as a <wsse:EncodedString> and indicates in its attributes (as necessary) the key identifier type (i.e. the <wsse:ValueType>), the identifier encoding type (i.e. the <wsse:EncodingType>), and any other parameters necessary to reference the security token. When a key identifier is used to reference a SAML assertion, the key identifier MUST contain as its element value the corresponding <saml:AssertionID>. The key identifier MUST also contain a <wsse:ValueType> attribute and the value of this attribute MUST be the wsse:KeyIdentifier/@ValueType from Table 2. When the <wsse:EncodingType>xsi:string. attribute is not specified, the element value of the key identifier MUST be encoded as When a key identifier is used to reference a SAML Assertion that MUST be acquired from an assertion authority, a <saml:AuthorityBinding> element MUST be contained in the <wsse:SecurityTokenReference> element containing the key identifier. The contents of the <saml:AuthorityBinding> element MUST be as defined in SAMLCore <#saml_core>. >-----Original Message----- >From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >Sent: Wednesday, January 21, 2004 11:28 AM >To: Chris Kaler >Cc: wss@lists.oasis-open.org; Levinson, Richard >Subject: Re: [wss] the saml token profile depends on non-global >attributes in key identifier/wsse schema does not support keyIdentifier >element extensibility > >Chris, > >Attribute and element extensibility are different. >You can have any attribute in keyIdentifier, but >you can't have any element. > >To use a keyIdentifier to reference an off msg >SAML assertion, we need to know the saml:location >and saml:binding attributes to be able to dereference >the assertion id. The saml attributes are not global, thus >they cannot be directly included in keyIdentifier via its >attribute extensibility (although they could be cloned). > >SAML defines a global element called AuthorityBinding that >contains the saml:location and saml:binding attributes. The >AuthorityBinding element could have been directly included >in keyIdentifier if EncodedString supported element extensibility. > >My long term preference is to use a Direct Reference, but SAML >is in the process of defining URI reference forms. > >My current thinking is that I will advocate including a >saml:AuthorityBinding >element at the top of the STR, when location and or binding attributes >are >needed to interpret a contained keyIdentifier. > >What do you think and thanks for answering. > >Ron >Chris Kaler wrote: > > > >>I believe if you trace back the type of EncodedString you will find >> >> >that > > >>it does support attribute extensibility. EncodedString extends >>AttributedString which allows for any attributes: >> >> <xsd:anyAttribute namespace="##other" processContents="lax"/> >> >>What am I missing? >> >>-----Original Message----- >>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>Sent: Tuesday, January 20, 2004 2:04 PM >>To: wss@lists.oasis-open.org >>Cc: Levinson, Richard >>Subject: [wss] the saml token profile depends on non-global attributes >>in key identifier/wsse schema does not support keyIdentifier element >>extensibility >> >>The schema for wsse:KeyIdentifier does not support element >>extensibility. >> >>The SAML token profile relies on non-global saml attributes (i.e. >>saml:local >>and saml:binding) to format keyIdentifier SecurityTokenReferences. >> >>The non-global attributes could be replaced with the global >>saml:AuthorityBinding >>element, if the wsse:KeyIdentifier supported element extensibility. >> >>There are 2 paths forward. >> >>. Modify the wsse:schema to allow any element to be included in >>keyIdentifiers >> >>. use Direct References with an optional contained AuthorityBinding >>element >> to reference SAML assertions, when the authority and binding must be >>sepcified >> to acquire the assertion. >> >>I am working on modifying the profile to take the latter approach, but >>would >>appreciate feedback from the TC. >> >>Any comments? >> >>Ron >> >><xsd:complexType name="KeyIdentifierType"> >>- >> <xsd:annotation> >><xsd:documentation>A security token key identifier</xsd:documentation> >></xsd:annotation> >>- >> <xsd:simpleContent> >>- >> <xsd:extension base="wsse:EncodedString"> >><xsd:attribute name="ValueType" type="xsd:anyURI"/> >></xsd:extension> >></xsd:simpleContent> >></xsd:complexType> >> >>Ron Monzillo wrote: >> >> >> >> >> >>>BTW, in section 3.3, we need to change the way SAML keyIdentifier >>>references >>>are composed, as the Binding and Location attributes are not global. >>>Perhaps we can >>>use the SAML AuthorityBinding construct, as apposed to its internal >>>attributes. >>> >>> >>> >>> >> >>To unsubscribe from this mailing list (and be removed from the roster >> >> >of > > >>the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgro u >> >> >p > > >>.php. >> >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]