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 <eran@hueniverse.com>
> *To:* Phil Hunt <phil.hunt@oracle.com>; "Manger, James H" 
> <James.H.Manger@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-bounces@ietf.org <mailto:oauth-bounces@ietf.org> 
> [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@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 <http://www.independentid.com>
> > phil.hunt@oracle.com <mailto:phil.hunt@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 <mailto:OAuth@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>