Hal, this looks good.
Some very intial comments on scenarios below
Hal Lockhart wrote:
>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
>
>
I noticed your suggestion that we pre-generate and SIGN the assertions.
I think we should focus on scenarios somwhere between your 2 and 3 that
demonstrate the use of the sender-vouches and holder of key to sign the
body.
In the case of sender-vouches we should try an unsigned by the authority
aassertion and sign both the assertion and the msg body, because when
signed assertions are used:
1. the holder of key and sender vouches mechanisms are very (as in too)
similar
[on the other hand, there is a variant of sender-vouches used for
transparent
impersonation with a confirmation key in which case the key
containing/identifying
assertion must be signed by the authority]
2. signing the assertion as in 3 (but also the body as in 2) gives us a
chance
to demonstrate the use of the security token transform - which was proposed
to support exactly this use case.
As discussed on the call, we should discuss how encryption should be
integrated with the SAML token profile. I agree that a key in or referenced
from a (holder-of-key) assertion could be used in the same manner that a
key in an x509 cert was used in our encryption scenarios.
Ron
>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
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
>
>
>
