OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-sx] Issue 101: Need additional SamlToken AssertionElements for Holder-of-Key and Sender-Vouches


How do you distinguish between Sender-Vouches and Bearer in that case then?
Both are signed.

-Greg


On 8/11/06 10:09 AM, "Martin Gudgin" <mgudgin@microsoft.com> wrote:

> As I mentioned on the call, I think that Holder-Of-Key is indicated by virtue
> of the SAML token being used as token that requires proof of key knowledge,
> for example, [Protection Token], [Endorsing Supporting Tokens], [Signed
> Endorsing Supporting Tokens].
> 
> Similarly, I think Sender-Vouches is indicated by virtue of the SAML token
> being used as a token that requires signing, for example, [Signed Supporting
> Tokens]
> 
> Gudge
> 
>> -----Original Message-----
>> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
>> Sent: 10 August 2006 23:25
>> To: Marc Goodner
>> Cc: Frederick Hirsch; Rich Levinson; ws-sx@lists.oasis-open.org
>> Subject: Re: [ws-sx] Issue 101: Need additional SamlToken
>> Assertion Elements for Holder-of-Key and Sender-Vouches
>> 
>> +1 on adopting one of Rich's proposals (TC to determine which)
>> 
>> This was one of the issues I noted with regard to the Interop
>> document when attempting to craft policy statements for the interop
>> scenarios:
>> 
>> "- how to state confirmation method requirement in policy (e.g. HoK
>> for SAML tokens)"
>> 
>> See
>> <http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/
>> 200607/msg00068.html>
>> 
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch
>> Nokia
>> 
>> 
>> On Aug 9, 2006, at 9:38 AM, ext Marc Goodner wrote:
>> 
>>> Issue 101.
>>> 
>>> -----Original Message-----
>>> From: Rich Levinson [mailto:rich.levinson@oracle.com]
>>> Sent: Tuesday, August 08, 2006 6:25 PM
>>> To: ws-sx@lists.oasis-open.org; Marc Goodner
>>> Subject: NEW Issue: Need additional SamlToken Assertion Elements for
>>> Holder-of-Key and Sender-Vouches
>>> 
>>> PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION THREAD
>>> UNTIL THE
>>> ISSUE IS ASSIGNED A NUMBER.
>>> The issues coordinators will notify the list when that has occurred.
>>> 
>>> Protocol:  ws-sp
>>> 
>>> 
>>> http://www.oasis-open.org/committees/download.php/18837/ws-
>>> securitypolic
>>> y-1.2-spec-ed-01-r07.pdf
>>> 
>>> Artifact:  spec
>>> 
>>> Type:    design
>>> 
>>> Title:
>>> 
>>>     Need additional SamlToken Assertion Elements for
>> Holder-of-Key and
>>> Sender-Vouches
>>> 
>>> Description:
>>> 
>>>     Comparable to the level of granularity defined for UsernameToken
>>> Assertions (lines 854-861 (NoPassword, HashPassword))
>>>      and X509Token Assertions (lines 1004-1024 several token
>>> types), the
>>> SamlToken Assertion needs token types of
>>>     sender-vouches and holder-of-key defined. As in the Username and
>>> X509 token cases, the WS 1.0 and WS 1.1
>>>     Saml Token profiles identify these token types as explicit use
>>> cases
>>> that the profile supports.
>>> 
>>> 
>>> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
>>>           see line 495
>>> 
>>> 
>>> http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-
>>> spec-os
>>> -SAMLTokenProfile.pdf
>>>           see line 672
>>> 
>>> Related issues:    None
>>> 
>>> Proposed Resolution:
>>> 
>>>     Add the following lines after line 1322 in section 5.3.8:
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlHolderOfKey
>>>           This optional element identifies that a SAML holder-of-key
>>> token should be used as
>>>           defined in [WSS: SAML Token Profile 1.0, 1.1].
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlSenderVouches
>>>           This optional element identifies that a SAML
>> sender-vouches
>>> token should be used as
>>>           defined in [WSS: SAML Token Profile 1.0, 1.1].
>>> 
>>>     The above proposal would require 2 elements to fully define the
>>> required token. An alternative
>>>     approach would be to explicitly define the 2 tokens for all 3
>>> supported versions as follows:
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10HolderOfKey
>>>           This optional element identifies that a SAML Version 1.1
>>> holder-of-key token should be used as
>>>           defined in [WSS: SAML Token Profile 1.0].
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10SenderVouches
>>>           This optional element identifies that a SAML Version 1.1
>>> sender-vouches token should be used as
>>>           defined in [WSS: SAML Token Profile 1.0].
>>> 
>>>         /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11HolderOfKey
>>>           This optional element identifies that a SAML Version 1.1
>>> holder-of-key token should be used as
>>>           defined in [WSS: SAML Token Profile 1.1].
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11SenderVouches
>>>           This optional element identifies that a SAML Version 1.1
>>> sender-vouches token should be used as
>>>           defined in [WSS: SAML Token Profile 1.1].
>>> 
>>>         /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11HolderOfKey
>>>           This optional element identifies that a SAML Version 2.0
>>> holder-of-key token should be used as
>>>           defined in [WSS: SAML Token Profile 1.1].
>>> 
>>>        /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11SenderVouches
>>>           This optional element identifies that a SAML Version 2.0
>>> sender-vouches token should be used as
>>>           defined in [WSS: SAML Token Profile 1.1].
>>> 
>>> 
>>> 
>> 
>> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]