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]>
[mailto:[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 <http://www.independentid.com>
> [email protected] <mailto:[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] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
