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:]
Sent: Wednesday, January 21, 2004 1:37 PM
To: Chris Kaler
Cc: ; 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:]
>Sent: Wednesday, January 21, 2004 11:28 AM
>To: Chris Kaler
>Cc: ; 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:]
>>Sent: Tuesday, January 20, 2004 2:04 PM
>>To:
>>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.
>>
>>
>>
>>
>>
>
>
>
