It seems like this would make what I see as the more common case -- getting a single access token from a flow -- more complicated. Everybody pays the overhead in order to support one limited use case, which is what brought about the request token in oauth1. I don't want to always have to grab "token[0]" from the response where before i just grabbed "token".
Also, this approach ties us to a hierarchical data representation format like JSON instead of being able to use anything that can hand us simple key-value pairs. Hashtables/dictionaries/associative-arrays are very easy to manipulate and understand in many languages. If we can do this in a way that doesn't create overhead for the single-token case and if we can figure out a way to serialize it in a flat way as well, then I'm all for it; but I don't think we should add this much complexity just to save a few round trips. I am in favor of Dick's proposal(s) for re-scoping and revoking existing tokens using the refresh token as credential. This would allow clients to grab a refresh token then make one more call each to grab whatever access tokens they wanted to. -- justin ________________________________________ From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Manger, James H [james.h.man...@team.telstra.com] Sent: Monday, May 24, 2010 9:18 PM To: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? Torsten, I obviously agree that supporting responses with multiple tokens is useful. My original suggestion (application/credentials http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) also had multiple tokens with just one refresh_token. I now think it would be simpler to understand, parse, specify, and agree on if we don't try to split fields between those that are common to all the tokens in a response and those that are specific to one token. A JSON array of JSON objects -- one JSON object per token -- is significantly simpler. If some information is duplicated in two tokens that is a very minor inefficiency (eg a few dozen extra bytes in one response). Marius, Supporting the swapping (down-scoping) of tokens with extra calls might be feasible, but it feels like a more complex and less flexible solution. It has more overhead (extra round trips). It would also need extra information to tell the client that swapping is possible, and for what scopes/servers/schemes/... it can, should or must be done. > The original access token (the one that came along the refresh token) would > be discarded. This doesn't meet some of the requirements. Tokens for HTTP and HTTPS are needed simultaneously, not sequentially. Similarly with tokens for a 'contacts' server and a 'calendar' server; or tokens to use with BASIC and TOKEN schemes etc. -- James Manger _______________________________________________ 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
