[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SAML Token Brainstorming
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]