RE: [wss] SAML Token Brainstorming

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

I am having trouble following some of the comments. Instead of point by
point responses, let me try to address the issues I have seen raised.

1. Signed Assertions. My assumption was that a WSS environment, it would be
common to pass around signed assertions and stick them in messages. I wanted
to exercise the various combinations of the pre-signed token with message
signing and encryption as well as signing of the token by the initial
sender. I figured that if we can do all these things w/o breaking the issuer
signature, than unsigned tokens should work fine. I would propose that the
issuer PK be agreed out of band, but that the receiver verify it each time
to make sure that it is still ok.

2. Encryption. What I had in mind for encryption was something like scenario
#3. Sign the request and encypt the response using the same PK. We could
also encrypt the request using an out-of-band key, but I don't feel strongly
about that. Similarly, we could sign the response using a second
holder-of-key assertion.

3. I don't understand the comments about the relationship between signing of
the assertion by the issuer and sender vouches. Maybe, like Irving, I just
do not understand the semantics of sender vouches. I thought that it was
just way for an authority to create a bearer token. This seems orthagonal to
the issue of some party changing the contents of the assertion.

What have I forgotten?

Hal

> -----Original Message-----
> From: Ron Monzillo [mailto:ronald.monzillo@sun.com]
> Sent: Tuesday, October 07, 2003 2:15 PM
> To: Hal Lockhart
> Cc: wss@lists.oasis-open.org
> 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_wor
kgroup.php.
>
>
>