RE: [wss] Groups - WSS-SAML-09.pdf uploaded

["Levinson, Richard" <rlevinson@netegrity.com>]

Ron,

I am responding to your up front comment and
will look at the other comments tomorrow.

As I understand what you are saying, you would 
prefer that the Signature/KeyInfo always point
to a token containing the invocation identity.

Although I had not looked at it from quite this
perspective, I agree that the sender-vouches as
currently construed has some questionable 
characteristics.

I think this arises from a basic shortcut that
is taken in the scenario which is having one 
signature sign both the assertion and the message.
This saves time by only having one signature to
create but as you have indicated it starts to open
up all other sorts of issues. One that has always
troubled me is that it kind of breaks the atomicity
of the assertion token, such that the assertion is
not valid outside the context of the message. Also,
it puts the path to the invocation identity in
a Signature/Reference rather than a Signature/KeyInfo.

In my opinion, the way this should be set up is that
the attester should first sign the assertion, and in
effect become the assertion authority (using an
enveloped signature), then sign the message using
standard WS practice, with the Signature/KeyInfo
pointing to the assertion.

This way the recipient can obtain the invocation 
identity from the token pointed to by Signature/KeyInfo.

Authentication then becomes a degenerate case of the 
holder-of-key authentication, where the "holder-of-key" is
now effectively also the assertion authority/ attester.