SAML Token Brainstorming

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

Here are some thoughts on the possible contents of a SAML Token Profile
Interop.

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.

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

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

So, does everybody agree so far?
Which combinations do people actually want to do? I sugest that 3 or 4
scenarios may be sufficient. Remember we can do different things on the
request and response.

Hal