Eran, Agree, having an array all the time would be a pain. Still, I maintain a +1 to explore this a wee bit further much as I hate to do so at this late stage.
Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-06-15, at 10:46 PM, Eran Hammer-Lahav wrote: > 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
