+1 Seems a reasonable approach/requirement.
Phil @independentid www.independentid.com [email protected] On 2011-06-17, at 1:02 PM, William J. Mills wrote: > This feels right to me. Additionally, any client consuming multiple tokens > (whcih would be new) shoudl be able to add something onto the token request > indicating they are capable of such. This means we never break existing > clients. > > From: Justin Richer <[email protected]> > To: [email protected] > Sent: Friday, June 17, 2011 12:15 PM > Subject: Re: [OAUTH-WG] issuing multiple tokens > > Incidentally, I'd like to clarify my position that the below or any other > kind of multi-token formatting doesn't belong in the core spec. > > -- Justin > > On 6/17/2011 9:46 AM, Justin Richer wrote: >> >> I completely agree that the single-token case needs to be left alone, and I >> rather like this idea. The AS would return something like: >> >> { >> access_token: [ >> { >> access_token: "1234656", >> expires_in: 3600, >> token_type: bearer >> }, >> { >> access_token: "abcdefg", >> expires_in: 3600, >> token_type: MAC, >> mac_stuff: "goes_here" >> } >> ], >> token_type: multiple >> } >> >> This would not only let clients who are doing the common one-token flow >> ignore the "multiple" token type, it would also allow for re-use of token >> storage libraries for the inner token bits. And you could go crazy and pass >> a multiple token full of multiple tokens, too. It's turtles all the way down! >> >> -- Justin >> >> On 6/16/2011 7:23 PM, William J. Mills wrote: >>> >>> Probably defining a token type of "multiple_tokens" would be my preference, >>> and if you get that back then you have to parse an array of {type, token}*. >>> What that array looks like could be JSON in the payload, or something >>> else. That leaves the single token use case alone. >>> >>> From: Eran Hammer-Lahav <[email protected]> >>> To: Phil Hunt <[email protected]>; "Manger, James H" >>> <[email protected]> >>> Cc: OAuth WG <[email protected]> >>> Sent: Wednesday, June 15, 2011 10:46 PM >>> Subject: Re: [OAUTH-WG] issuing multiple tokens >>> >>> 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: [email protected] [mailto:[email protected]] 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 >>> > [email protected] >>> > >>> > >>> > >>> > >>> > >>> > 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 >>> > > [email protected] >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > [email protected] >>> > https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
