[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]