RE: [wss] SAML Token Brainstorming

["Mishra, Prateek" <pmishra@netegrity.com>]

Token References

The spec currently includes keyname, but I recall discussion (at the SAML
F2F?) to drop it.

That gives us:

1. Key Identifier
2. Direct Reference
3. Embedded Reference

The spec defines the use of two Subject Confirmation Methods:

1. Holder of Key
2. Sender Vouches

I suggest we pre-generate and sign the Assertions we use, perhaps one sender
vouches and two holder of key.

[Prateek]
Hal, the sendervouches case does not require the assertion to be signed
separately. The simplest case is one in which the sender generates an
assertion (describing a subject) and binds it with a signature to a SOAP
message. The case where the assertion is signed is a significant extension
of the base case.
[/Prateek]

It seems to make the most sense to me to send an SSO Assertion (AuntN +
optional attributes) with Sender Vouches in the Security header.

[Prateek]
I do not think we need to import the complexities of the web browser profile
into this demonstration. The SAML profile document describes addition of
SAML assertions to SOAP messages with subject confirmation method set to
"SenderVouches" or "Holder of Key". That should be enough.

I don't see the need for specifying the contents of the SAML assertion
beyond the required elements (e.g., Subject Confirmation Method, keys). One
or more statements with the required properties are present; why do we need
to go further.
[/Prateek]


It makes sense to send an Assertion with an Attribute Statement with Holder
of Key and use the key for signature and/or encryption. Since we have
already tested X.509, I propose we just use a naked PK.

Among the prior Interop scenarios we have:

1. send token in header
2. sign body with key in token
3. sign some token with key in token
4. encrypt body with key in token
5. encrypt some token with key in token
6. combinations of the above

[Prateek]
Hal, the analogy is not going to be exact as SenderVouches and HolderOfKey
have somewhat different requirements:

1. Add SAML assertion to SOAP header.
   (a) Assertion is a SenderVouches assertion, information about sender
authenticity is acquired by some other means (e.g., SSL).

2 SenderVouches Case: Assertion is added to header and a digital signature
by the sender over the assertion and the body is added. Sender certificate
or public key is provided with the signature.

3 HolderOfKey Case: Signed SAML assertion is added to header with public key
information. A second signature binds the assertion to the SOAP payload.

We also need to capture similar responses.

I don't see how encrypting the body interacts with SAML assertions. Are you
proposing that the key used to sign the assertion also be used for
encryption? 

Encrypting SAML assertions using WS-Sec Core technology does makes sense to
me. However, I don't see what differentiates this from vanilla encryption of
header components. 

[/Prateek]