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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: Re: [wss] error in wss-v1.1-spec-cs-SAMLTokenProfile 3.5.2.3 and 3.5.2.4 examples


Ok, I finally understand -- thanks for your patience. I do think  
that, for an example in the sender-vouches section of the document,  
this construction is more confusing that it needs to be. Even just  
including the referenced sender-vouches assertion as an exhibit would  
probably help to clarify things.

Thanks,

-Greg

On Feb 27, 2006, at 11:00 AM, Ron Monzillo wrote:

> Greg Whitehead wrote:
>
>> I think now I'm even more confused now.
>>
>> Isn't this section supposed to show how one would use a sender-  
>> vouches assertion? I guess it's fine to show use of a holder-of- 
>> key  assertion to sign the message, but wouldn't the sender- 
>> vouches  assertion need to be included if it's in play? Otherwise,  
>> this is  just a holder-of-key example.
>
> It is included in that it is signed info by reference
>
> <ds:Reference URI="#STR1">
> <Transforms>
> <ds:Transform
> Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-soap-message-security-1.0#STR-Transform">
> <wsse:TransformationParameters>
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </wsse:TransformationParameters>
> </ds:Transform>
> </Transforms>
> <ds:DigestMethod
> Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>...</ds:DigestValue>
> </ds:Reference>
>
> for a sender-vouches assertion to be "used" according to the  
> profile it must be bound
> by the attesting entity to the vouched for message content (so that  
> the receiver...).
>
> A signature over the message content and the vouched for assertion  
> is one way
> (i.e., the typical way) to accomplish this.
>
> In the example the key identified in the hok assertion is used by  
> the attesting entity to sign what is
> being attested for - in  this case the sender-vouches assertion   
> and the associated msg content -
> thus the composition in the example.
>
> the use of the hok assertion to provide the signing key is not the  
> focus of the example.
>
> Ron
>
>>
>> -Greg
>>
>> On Feb 27, 2006, at 8:01 AM, Ron Monzillo wrote:
>>
>>> Greg Whitehead wrote:
>>>
>>>> These sections are supposed to show examples of the sender- 
>>>> vouches  subject confirmation method, but the assertions in the  
>>>> examples  are holder-of-key.
>>>>
>>>> -Greg
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe from this mail list, you must leave the OASIS TC  
>>>> that
>>>> generates this mail. You may a link to this group and all your  
>>>> TCs  in OASIS
>>>> at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/  
>>>> my_workgroups.php
>>>
>>>
>>> Hi Greg,
>>>
>>> The attesting entity signed the sender-vouches assertion using a   
>>> key identified
>>> by a (second) hok assertion. The hok assertion is in the msg.  
>>> The  sender-vouches
>>> assertion is not in the msg.
>>>
>>> The example is an all-saml formulation. The second assertion  
>>> could  have been
>>> an x509 certificate or a kerberos service ticket (for example) -   
>>> and the signing ket could
>>> also have been conveyed by reference.
>>>
>>> How this clarifies things, and thanks,
>>>
>>> Ron
>>>
>>>>
>>>> 3.5.2.3 Example V1.1
>>>> The following example illustrates an attesting entity’s use of  
>>>> the  sender-vouches subject confirmation
>>>> method with an associated <ds:Signature> element to establish  
>>>> its  identity and to assert that it has
>>>> sent the message body on behalf of the subject(s) of the V1.1   
>>>> assertion referenced by “STR1”.
>>>> The assertion referenced by “STR1” is not included in the  
>>>> message.  “STR1” is referenced by
>>>> <ds:Reference> from <ds:SignedInfo>. The ds:Reference> includes   
>>>> the STR-transform to
>>>> cause the assertion, not the <SecurityTokenReference> to be   
>>>> included in the digest calculation.
>>>> “STR1” includes a <saml:AuthorityBinding> element that utilizes   
>>>> the remote assertion referencing
>>>> technique depicted in the example of section 3.3.3.
>>>> The SAML V1.1 assertion embedded in the header and referenced  
>>>> by  “STR2” from <ds:KeyInfo>
>>>> corresponds to the attesting entity. The private key  
>>>> corresponding  to the public confirmation key occurring
>>>> in the assertion is used to sign together the message body and   
>>>> assertion referenced by “STRI”.
>>>
>>>
>>>
>>>
>>
>
>



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