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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
