I'm still a newbie here so someone please correct me if I'm wrong, but I believe the Assertion Flow was intentionally left generic to serve as an extension point for profiling more specific types of assertions/tokens being exchanged for OAuth Access Tokens (or allowing for proprietary usage). The use of SAML 2 tokens is suggested in draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along the lines of what Thomas outlines though I don't know enough about Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's use case could be addressed by profiling a flow that defines an Access Token being exchanged for a different Access Token? And the initial bootstrapping could maybe be accomplished via the Client Credentials Flow?
On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono <hardj...@mit.edu> wrote: > > > Lisa, > > > > I’m also looking at the assertion flow right now > > and wondering if I could use it to “swap” a > > Kerberos service-ticket for an OAuth Access-Token. > > > > In particular, I would like to: > > > > (1) Wrap the KRB AP_REQ message within a SAML-assertion > > (eg. using the existing WSS Token Profile standard), > > > > (2) Deliver it using the OAuth assertion flow to a special > > Kerberized-service (or IdP or OP), who then verifies > > the Authenticator and Service-Ticket within > > the AP_REQ message. > > > > (3) Obtain in return an OAuth Access-Token with > > the same lifetimes/expiration as defined in the original > > service-ticket (in the AP_REQ request). > > > > (4) Present the Access-Token to an OAuth Resource Server. > > > > (ps. Alternatively, I could use the Kerberos delegation feature > > but that may be more complicated). > > > > > > I think Section 3.10 needs more fleshing-out. > > > > /thomas/ > > > > > > __________________________________________ > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Lisa Dusseault > Sent: Wednesday, June 02, 2010 1:33 PM > To: oauth > Subject: [OAUTH-WG] Assertion flow and token bootstrapping > > > > I've been trying to understand the use case for the assertion flow > (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . > Conversely, I have a use case for bootstrapping, and I'm trying to > understand if the assertion flow is the right flow for that use case. > > The bootstrapping use case I have in mind is to allow a client to interact > with a related set of services by bootstrapping from client secret to an > access token, and then from that access token to other access tokens. For > example, in a "login" interaction the client would get a generic access > token. Later, to use various services -- access to personal data, access to > friends' data, attempts to do uploads -- the client would ask the security > token server for access to new resources by URI, and if access was granted, > receive new access tokens which could be used on those services. The client > secret is not reused very often, and policy is centralized. > > This seems similar to other use cases being discussed and so it's possible > my main point of confusion is trying to tie this to the assertion flow > instead of something else. > > The assertion flow has the right number of parties involved, and it could > certainly be hacked/extended to do bootstrapping: instead of the client > secret, the general session access token could be used, and the "assertion" > field can contain anything including the URI of the service that the client > now wants. However I wondered if something less generic could make this > more interoperable. > > Any thoughts? > > Thanks, > Lisa > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
