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 <e...@hueniverse.com>
To: Phil Hunt <phil.h...@oracle.com>; "Manger, James H"
<james.h.man...@team.telstra.com>
Cc: OAuth WG <oauth@ietf.org>
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: 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
