Re: [OAUTH-WG] Assertion flow and token bootstrapping

[Eran Hammer-Lahav <[e-mail]>]

As long as:

- You can provide a URI identifier for the assertion format you are going to use, and
- The authorization server can do something useful with the assertion provided and decide if it should grant an access token

Then sure, you can use the assertion flow for utilizing any other trust framework for obtaining an access token.

EHL

From: [e-mail] [mailto:[e-mail]] On Behalf Of Lisa Dusseault
Sent: Wednesday, June 02, 2010 10:33 AM
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