[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 >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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]