Re: [wss-comment] Problem with Sender Vouchers example in SAML TokenProfile 1.0 and 1.1

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Tom Scavo wrote:
> On Wed, Nov 12, 2008 at 9:51 AM, Ron Monzillo <Ronald.Monzillo@sun.com> wrote:
> 
>>Tom Scavo wrote:
>>
>>>On Tue, Nov 11, 2008 at 7:58 PM, Glen Mazza <glen.mazza@gmail.com> wrote:
>>>
>>>
>>>>It would be nice if the docs could be updated to remove the confusion.
>>>
>>>Not likely since the WSS TC is closed.
>>
>>Please look at the examples in the WSS STP more closely.
> 
> 
> I have, on many occasions, and there are many flaws.  In the first
> example on lines 191--227 of SAML Token Profile 1.1, there are the
> following problems:
> 
> - The type of the <saml:SubjectStatement> element is abstract,
> therefore it may not be used as a concrete element in a SAML V1.1
> assertion.  The <saml:SubjectStatement> element is an extension point
> only.
> 
> - The SAML V1.1 assertion has two different subjects.  Although this
> is legal, there is no use for such an assertion.  In fact, SAML V2.0
> removes this capability and therefore the two examples in this section
> are not equivalent.  Note there is a spec that calls out this issue:
> 
> http://wiki.oasis-open.org/security/SamlSubjectProfiles
> 
> - Both sender-vouches and holder-of-key are used in the same
> assertion.  Since an assertion is only as strong as its weakest
> subject confirmation method, this is not a realistic example to say
> the least.
> 
> That's just the first example :-)
> 
Tom,

All of section 3.2 including the example you are now commenting on was 
written to illustrate diffences (relevant to the STP) between v1.1 and 
v2.0. Your comments above, suggest that you attributing some other 
purpose to this section. That said, it would still be wothwhile to
either correct the syntax, or make the examples less detailed. perhaps 
there is still enough activeity within the WSI to make the corrections 
in that version of the profile.

Glen asked for clarification regarding the sender vouches examples

http://www.nabble.com/Need-clarification-on-SAML-Sender-Vouches-vs.-Holder-of-Key-methods-p20447888.html

I may have misunderstood your responses, but the answer to his request 
for clarification remains as copied below.

I have only been causually following the work you are doing on 
SubjectConfirmation profiles. I'll try to find time to take a closer look.

Ron

The examples being referred to depict the use of SAML tokens to allow 
one party (aka, the sender) to attest (i.e., vouch for) for another.

There are 2 SAML assertions. The assertion (referrenced by STR2) 
corresponds to the sender and is HOK confirmed . The assertion that 
correspomds to the party being vouched for (as referrenced by STR1) is 
SV confirmed.

The sender is using its key to sign and thus bind the SV confirmed 
assertion to the message. As such, the sender is using its key to vouch 
for the claims appering in the SV confirmed assertion (which apply to 
another entity).

The HOK assertion of the sender could be replaced with the X509 cert of 
the sender, and the effect would be equivalent. The example shows how 
the same effect can be achieved using only SAML assertions.

The example also shows the use of the STR transform during signing of 
the vouched for assertion, and as such the vouched for assertion does 
not occur in the message. In retrospect, including the vouched for 
assertion in the msg (and depicted the use of the STR transform in 
another example) would have simplified the example, and allowed folks to 
recognize the presence of the SV confirmed assertion.