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 <jric...@mitre.org>
To: oauth@ietf.org
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 <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_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
