RE: [wss] SAML Token Brainstorming

["Hal Lockhart" <hlockhar@bea.com>]

Are these semantics specific to the WSS SAML Toke Profile? They are not
mandated by SAML as far as I am aware.

> Holder-of-key requires that the assertion contain an authority
> signature and
> that the sender sign the msg. The sender need not sign the assertions.

According to SAML any assertion may or may not be signed.

The Holder of Key is intended to allow the Subject (who may or not be the
sender) to prove that is in fact the Subject refered to by demonstrating
that it has knowledge of the expressed or implied secret, typically by use
os some cryptographic function such as a signature.
>
> Except for the special case described below, Sender-vouches requires
> that the sender sign both the assertion and the msg. The authority need
> not sign the asertion (although doing so allows the relying party
> to verify that the authority has established the binding of attributes
> to the subject).

In the case of the SAML POST profile (for which the sender vouches
confirmation method was invented) the authority signs the assertion, not the
sender. (It follows a V path from authority to Browser (sender) to relying
party, via a web form.)

As I understand it, sender vouches is just like saying "this is my birth
certificate, here in my hand." In other words there is no sure way of
assocating the sender with the assertion.

This is my understanding of what SAML specifies. If we are adding new
semantics, we should chose new subject confirmation methodds, not change
their semantics.


> To do request encryption, I thought we would more likely depend on
> the X509 profile to pass an encrypted key, in which case, I
> thought we would
> likely reuse the encrypted key for the response. We could, for
> response only
> encryption, reuse the key from a SAML assertion (used to sign the request)
> to define an encrypted key, if we think response only encryption
> is an important use case.
>
> Is there any reason why it would be bad to demonstrate a sign and encrypt
> scenario that synergized both the x509 and Saml token profiles?

Why not just exchange it in advance? In real life it would likely be
obtained from something like WSDL.


> I don't think I saw Irving's comments,

Irving just has said repeatedly that he doesn't see how an assertion with
sender vouches differs semantically from an assertion with no subject
confirmation method.

Hal