If I understand you correct, then you could utilize the assertion flow
as follows:
Put the generic token into the assertion parameter, set the scopes
parameter to the scope(s) of the service your client wants to interact
with and use the client credentials as described. If the AS supports
such a token swap, then it should respond with a new access token
applicable for the target services. Pre-Requisite: The original token
must have been authorized for the target service (scope). How do you
want to achieve that? Which flow do you want to obtain the first access
token?
Alternatively, your client could also obtain all tokens required to
access the target services in the initial authorization flow. Please
take a look on the thread about multiple access tokens from one
authorization flow
(http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html).
regards,
Torsten.
Am 02.06.2010 19:32, schrieb Lisa Dusseault:
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
