[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
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? -----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_workgrou p >.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]