OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wss] SAML Token Brainstorming

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
>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 

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) 
[on the other hand, there is a variant of sender-vouches used for 
impersonation with a confirmation key in which case the key 
assertion must be signed by the authority]

2. signing the assertion as in 3 (but also the body as in 2) gives us a 
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.


>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.
>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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]