It is not an important enough feature. Parsing an array response when 99.99% will be a single object array is annoying. Also, what would you return in case of error? A single object? What is the client supposed to do if it gets an empty array? Array with more than one token?
*This* would be the hack... If this is something people want to deploy, a full proposal end-to-end is required. And not now. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Hunt > Sent: Wednesday, June 15, 2011 10:40 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] issuing multiple tokens > > +1 > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-06-15, at 10:01 PM, Manger, James H wrote: > > > Torsten Lodderstedt needs to issue multiple tokens; Igor Faynberg said +1 > to that; John Bradley identified that OpenID Connect needs to request > multiple tokens; Eran Hammer-Lahav even mentioned a no-token flow as > something that could make sense; ... > > > > Issuing 0, 1 or more tokens looks like an important enough feature to fix > now, instead of trying to hack it in after the spec is finalised. > > > > > > Changing the access token response [5.1] to be a JSON array of JSON > objects (one JSON object per issued token) seems like a simple way to get > this important functionality -- with very limited overhead for services that > will > only ever issue a single token, and client written just for those services. > > > > P.S. Does Facebook return a JSON object for its access token response (as > in draft-ietf-oauth-v2-12 that they reference), or x-www-form-urlencoded > as the example at http://developers.facebook.com/docs/authentication/ > implies [4th screen shot down]? > > > > -- > > James Manger > > > > > > Eran said (on a different thread): > > > > ...if the client can authenticate with the authorization server. Why not > > just > include the client identifier and user identifier and let the authorization > server lookup what the user already authorized? > > > > > > Igor Faynberg wrote: > > > > +1 > > > > Torsten Lodderstedt wrote: > >> Hi, > >> > >> I also see the need to request and issue multiple tokens in a single > >> authorization process. There has already been some discussion about > >> this topic roughly a year ago: > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html. > >> - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html > >> > >> We at Deutsche Telekom have implemented an OAuth 2.0 extension > >> supporting that use case. It's called "bulk authorization". > >> > >> Would that be an interessting topic we could discuss at IETF-81 for > >> the re-chartering? I could present our approach there. > >> > >> regards, > >> Torsten. > > > >> Am 10.06.2011 21:08, schrieb John Bradley: > >>> We have identified the need to request multiple tokens as one issue > >>> that we would have to extend. > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
