Subject: Re: [OAUTH-WG] Proposed OAuth Extensions

From: John Bradley <[email-masked]>
Date: Fri, 10 Jun 2011 15:08:23 -0400

Shane,

We have been working on openID Connect (formerly known as openID AB) for some time.

If there are standard ways to do things in OAuth 2.0 that we can reuse then it saves us from inventing custom extensions for openID Connect.

We have identified the need to request multiple tokens as one issue that we would have to extend.

Certainly FaceBook is doing that now.

We have been working on a standard token/assertion format (JWT) that can be signed and encrypted.  That will be submitted as a separate spec.

Facebook has their own signature that they have been using for a while.  I don't know that we are going to get 100% convergence on token formats overnight.

From PAPE it turns out that one of the things people found most useful was the max-auth-age request to force interactive authentications.   

For SSO use we also need to be able to request a PAPE policy/ AuthnContext.  That may however be specific to Connect and less useful in general OAuth.

We want to invent as little as possible outside of OAuth as possible.  However we are mindful of OAuth deadlines so the Connect working group has been trying to track the spec as much as possible without requesting changes.

I understand Paul's request for those features, and they would make life easier for those of us working on SSO.  

The details probably need more discussion, on types of tokens names etc.

Regards
John Bradley

> 	• From: Shane B Weeden <sweeden at au1.ibm.com>
> 	• To: Paul Tarjan <pt at fb.com>
> 	• Cc: "oauth at ietf.org" <oauth at ietf.org>
> 	• Date: Tue, 7 Jun 2011 13:16:03 +1000
> 	• In-reply-to: <CA12D2B2.1CB84%pt at fb.com>
> 	• References: <CA12D2B2.1CB84%pt at fb.com>
> Just an observation - some of this function seems to have direct parallels
> in OpenID.
> E.g.
> display=none sounds very much like checkid_immediate
> prompt=xxx seems like a direct correlation to the PAPE extension
> 
> 
> Could things like signed_request and nonce be considered part of a custom
> token format in a separate token spec rather than part of the core -
> provided the client can be token-type-aware?
> 
> 
> 
> 
> From:	Paul Tarjan <pt at fb.com>
> To:	"oauth at ietf.org" <oauth at ietf.org>
> Date:	07-06-11 11:57 AM
> Subject:	[OAUTH-WG] Proposed OAuth Extensions
> Sent by:	oauth-bounces at ietf.org
> 
> 
> 
> Hi fellow OAuthers,
> 
> As we discussed at the meeting there are a few extensions that we'd like
> to implement. To do this, we'd like the response_type to be extensible. We
> are proposing two new values. "none" and "signed_request token" (and
> "token signed_request" for symmetry). Or if you want to turn response_type
> into a space separated list, that would work too.
> 
> I'm also including our other extension parameters so you can see what we
> are planning incase others need similar functionality.
> 
> 
> ---
> response_type=none
> 
> If this is specified then no code nor token is passed to the redirect_uri.
> This is very useful when the authentication will be done via other means
> (like the display=none parameter, or Facebook's canvas iframe).
> 
> Example:
> 
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=150629244948164&
>   redirect_uri=
> http://apps.facebook.com/ptarjan/&
> ;
>   response_type=none
> 
> (shows user the permission dialog then redirects to)
> 
> 
> http://apps.facebook.com/ptarjan/
> 
> 
> (or if they click cancel)
> 
> 
> http://apps.facebook.com/ptarjan/
> ?
>   error=access_denied&
>   error_description=...&
>   state=...
> 
> 
> ---
> response_type=signed_request
> 
> This response type is used to tie the Javascript SDK to a server-side SDK.
> It is used in conjunction with response_type=token and display=none. It
> sends a "signed_request" along with the response, which is a signed blob
> that we expect the JS library to dump into a cookie for the server SDK to
> read and validate. The JS SDK will also look inside of it (without
> verifying the signature) to see the user's ID. That is safe because the JS
> SDK uses state and only handles responses it's expecting.
> 
> The signed_request will contain:
> 
>   user_id   (provider specific id string)
>   issued_at (UNIXTIME)
>   code      (optional. OAuth code issued with redirect_uri set to ""
>              since the server won't know which URL it was issued on)
>   client_id (optional. Needed by Google for 4th party auth)
>   audience  (optional. Google's public key crypto)
>   ...       (other provider specific data)
> 
> Example:
> 
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=150629244948164&
>   redirect_uri=
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#&
> ;
>   display=none&
>   response_type=token signed_request
> 
> 302s to
> 
> 
> https://s-static.ak.fbcdn.net/connect/xd_proxy.php#
> 
>   access_token=...&
>   expires_in=...&
>   signed_request=abcd...
> 
> And the JS SDK then does
> 
> setcookie("fbc_"+client_id, signed_request)
> 
> 
> ---
> display=none
> 
> This means the user never will see a dialog and is meant to be opened in
> an iframe by javascript to asynchronously get an access_token or discover
> the user's state.
> 
> Example:
> 
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=150629244948164&
>   redirect_uri=
> https://example.com/&
> ;
>   display=none&
>   response_type=token
> 
> If the user is not logged into Facebook, this endpoint 302s to
> 
> 
> https://example.com/#
> 
>   error=unknown_user
> 
> If the user is logged in but hasn't authorized this app, it 302s to
> 
> 
> https://example.com/#
> 
>   error=not_authorized
> 
> 
> If the user has authorized the app then it 302s to the normal OAuth output
> 
> 
> https://example.com/#
> 
>   access_token=...&
>   expires_in=...
> 
> 
> ---
> prompt=
> 
> A parameter that changes some things with the OAuth prompt. These can be
> specified as a space/comma separated string.
> 
> prompt=login
> 
> This forces the user to enter their password again.
> 
> prompt=consent
> 
> This always shows the "Do you allow this app" dialog, even if they
> consented before. Google will only issue long lived tokens when the user
> clicks something.
> 
> prompt=secure
> 
> The user must be verified by secure (https) cookies. This protects the app
> from firesheep attacks.
> 
> prompt=select_account
> 
> The user will be shown a dialog to select amongst their connected accounts
> (Google wants this for multiple connected accounts).
> 
> 
> ---
> nonce=
> 
> If this parameter is specified, the nonce is encoded in the access_token,
> which is then accessible via a "Token Info Endpoint". This is paired with
> prompt=login to guarantee the user put in their password before they buy
> something expensive with their paypal account.
> 
> It is limited to a 20 character opaque string, but we recommend base64url
> encoding a set of random bits.
> 
> Example:
> 
> http://www.facebook.com/dialog/OAuth
> ?
>   client_id=150629244948164&
>   redirect_uri=...
>   nonce=some_string
>   response_type=code
> 
> Does exactly the same OAuth flow, except when they hit
> 
> https//graph.facebook.com/access_token?access_token=...
> 
> They get back json with a key "nonce" being the nonce encoded inside the
> Token.
> 
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> 
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 11 Jun 2011 09:30:20 +0200

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.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 13 Jun 2011 13:42:11 -0400

+1

Igor

Torsten Lodderstedt wrote:
> authorization process. There has already been some discussion about 
> this topic roughly a year ago:
> Would that be an interessting topic we could discuss at IETF-81 for 
> the re-chartering?  I could present our approach there.
>
> regards,
> Torsten.
>
> [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Jun 2011 21:58:23 -0400

On Sat, Jun 11, 2011 at 3:30 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> We at Deutsche Telekom have implemented an OAuth 2.0 extension supporting
> that use case. It's called "bulk authorization".
>

A reminder: We won't be discussing rechartering until we have the
currently chartered documents in to the IESG, which means successfully
through working-group last call.

So those who want to talk about extensions and additions -- and
rechartering -- should have a good bit of enthusiasm to ensure that we
get those documents done tout de suite.

Barry, as chair

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 14 Jun 2011 01:05:35 -0400

Barry,

I think there has been a confusion.  I also thought that the 
rechartering was to be discussed at the July meeting; the IETF call for 
rechartering was issued on May 31.

My question: has the rechartering discussion been closed in the WG?  (If 
so, I guess I missed the point when it happened.)

Igor

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Jun 2011 01:20:48 -0400

> I think there has been a confusion.  I also thought that the rechartering
> was to be discussed at the July meeting; the IETF call for rechartering was
> issued on May 31.

Right, and that call was not for discussion of rechartering, but for a
review of the specific proposed charter.

The charter that we discussed here was sent out for internal review on
31 May, and was approved by the IESG last Thursday -- that should be
officially announced any time now.  That charter, if you recall, was
very focused and included milestones for submitting OAuth 2.0, bearer
tokens, and MAC auth to the IESG in July and August, and discussion of
rechartering again, for further work, in October.

We won't be discussing rechartering in Québec, unless we've finished
those three documents already.  That seems unlikely.  But if we can do
it, tant mieux.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 10:11:18 +0100

> those three documents already.  That seems unlikely.  But if we can do

Right. I really hope to see documents for AD review or at least
being done or almost done WGLC before Quebec. Time is already very
tight for that to happen: if a 2 week WGLC started say in one week,
(June 21) then that would only leave 4 days from the end of WGLC
(July 5) until the I-D submission deadline (July 11) for Quebec.

In terms of extensions/rechartering, there are two ways to look at
this:

1 - the AD is being a PITA about this
2 - the WG has existed since late 2008 and really needs to produce
    results before moving on, as was agreed between the WG, AD and
    the IESG very very recently (last Thursday), the relevant part of
    the new charter being "Milestones will be added for the later
    items *after* the near-term work has been completed."

I'm ok with folks believing either:-)

To be concrete, there's no point in discussing rechartering at
this stage, because, as AD, I'm just not going to push any new
charter to the IESG until the current milestones are sufficiently
advanced. (At present, I interpret that to mean entering IETF
LC, which is after WGLC and AD review.)

So: what Barry said - please concentrate on getting the current
work finished. (Not perfect, but with rough consensus in the WG.)

S.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Jun 2011 15:01:34 +1000

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 22:31:52 -0700

My comment was not about not issuing an access token, but about the need for a refresh token *and* client authentication.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Wednesday, June 15, 2011 10:02 PM
> To: OAuth WG
> Subject: [OAUTH-WG] issuing multiple tokens
> 
> 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
> 
> 
> ...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
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Jun 2011 22:39:50 -0700

+1

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 22:46:01 -0700

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

> 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-masked]
> 
> 
> 
> 
> 
> > 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; ...
> >
> > 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
> > 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/

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Jun 2011 23:08:02 -0700

Eran,
Agree, having an array all the time would be a pain.

Still, I maintain a +1 to explore this a wee bit further much as I hate to do so at this late stage.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 16 Jun 2011 16:23:37 -0700 (PDT)

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-masked]>
To: Phil Hunt <[email-masked]>; "Manger, James H" <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Wednesday, June 15, 2011 10:46 PM
Subject: Re: [OAUTH-WG] issuing multiple tokens

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 17 Jun 2011 14:04:01 +1000

> [Issuing multiple tokens] is not an important enough feature. Parsing an array response when

> 99.99% will be a single object array is annoying.

I would agree... if I believed the 99.99%, but not if it will be 80% and falling in a year or two.

A major benefit of OAuth2 is that resource servers only handle limited-lifetime, limited-capability access tokens so there is limited damage and easier recovery if one resource service is compromised. If the same access token works at all the resource servers that a client app uses, then an attacker that compromises one resource server can re-use the access tokens elsewhere. The bigger your portfolio of services, the worse the risk.

> Also, what would you return in case of error? A single object?

Yes. It is not that hard to test if JSON.parse(...) returns an array or a single object with an error field, or to notice the 4xx status code.

> What is the client supposed to do if it gets an empty array?

The delegation succeeded, but you don't need to use temporary credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie was issued, perhaps the service is using URIs-as-capabilities...). Continue on to use the API.

> Array with more than one token?

If the client app hasn't bothered to write the extra code to handle multiple tokens then it just uses the first token. If separate tokens are now needed for servers that previously shared the same token, then the service has made a deliberate decision to increase security in a way that wasn't backwardly compatible.

> *This* would be the hack... If this is something people want to deploy,

> a full proposal end-to-end is required. And not now.

I few proposals have been made in the past. Some try hard to leave the single token case alone, but always at a cost to complexity: eg the first token needs to be handled differently to the other tokens.

Responding to William Mills' comments:

>> 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.

This is a good example of how it is awkward to add multiple token support later.

With this suggestion a service that starts issuing multiple tokens (eg for clients to access an enhanced version of an API) can't just add an extra token for the enhanced API that old clients will ignore. Instead, it has to change the top-level token_type, which will fail in all old clients. It also leaves other top-level mandatory fields such as access_token with confusing semantics.

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 22:25:47 -0700

I'm standing behind my 99.99% projection for the next 5 years.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, June 16, 2011 9:04 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] issuing multiple tokens

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 17 Jun 2011 09:40:33 +0200

this is kind of a self-fulfilling prophecy. If we do not encourage  
implementors to use service-specific tokens by supporting it in OAuth  
most people will not consider it.

As James pointed out, there are good reasons to use service-specific  
tokens in multi-service environments. That's why Deutsche Telekom  
employs a strict security policy to use different tokens for different  
services. And as a multi-service provider an increasing percentage of  
our apps need to access multiple services. That's why we have  
implemented support for issuing multiple tokens in a single  
authorization flow. We will have this feature in production before  
IETF-81.

regards,
Torsten.

Zitat von Eran Hammer-Lahav <[email-masked]>:

> A major benefit of OAuth2 is that resource servers only handle  
> limited-lifetime, limited-capability access tokens so there is  
> limited damage and easier recovery if one resource service is  
> compromised. If the same access token works at all the resource  
> servers that a client app uses, then an attacker that compromises  
> one resource server can re-use the access tokens elsewhere. The  
> bigger your portfolio of services, the worse the risk.
>
> Yes. It is not that hard to test if JSON.parse(...) returns an array  
> or a single object with an error field, or to notice the 4xx status  
> code.
>
> The delegation succeeded, but you don't need to use temporary  
> credentials (perhaps client auth is sufficient, perhaps a [MAC]  
> cookie was issued, perhaps the service is using  
> URIs-as-capabilities...). Continue on to use the API.
>
> If the client app hasn't bothered to write the extra code to handle  
> multiple tokens then it just uses the first token. If separate  
> tokens are now needed for servers that previously shared the same  
> token, then the service has made a deliberate decision to increase  
> security in a way that wasn't backwardly compatible.
>
> I few proposals have been made in the past. Some try hard to leave  
> the single token case alone, but always at a cost to complexity: eg  
> the first token needs to be handled differently to the other tokens.
>
>
> With this suggestion a service that starts issuing multiple tokens  
> (eg for clients to access an enhanced version of an API) can't just  
> add an extra token for the enhanced API that old clients will  
> ignore. Instead, it has to change the top-level token_type, which  
> will fail in all old clients. It also leaves other top-level  
> mandatory fields such as access_token with confusing semantics.
>
>
> --
> James Manger
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 17 Jun 2011 00:46:26 -0700

OAuth has been successful because of its simple architecture and because it is based on actual deployment experience. Offering multi-token responses would be premature standardization. I am not convinced that adding it later would entail any real technical difficulty.

EHL 

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Friday, June 17, 2011 12:41 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; OAuth WG
> this is kind of a self-fulfilling prophecy. If we do not encourage implementors
> to use service-specific tokens by supporting it in OAuth most people will not
> consider it.
> 
> As James pointed out, there are good reasons to use service-specific tokens
> in multi-service environments. That's why Deutsche Telekom employs a strict
> security policy to use different tokens for different services. And as a multi-
> service provider an increasing percentage of our apps need to access
> multiple services. That's why we have implemented support for issuing
> multiple tokens in a single authorization flow. We will have this feature in
> production before IETF-81.
> 
> regards,
> Torsten.
> 
> > limited-lifetime, limited-capability access tokens so there is limited
> > damage and easier recovery if one resource service is compromised. If
> > the same access token works at all the resource servers that a client
> > app uses, then an attacker that compromises one resource server can
> > re-use the access tokens elsewhere. The bigger your portfolio of
> > services, the worse the risk.
> >
> > credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie
> > was issued, perhaps the service is using URIs-as-capabilities...).
> > Continue on to use the API.
> >
> > multiple tokens then it just uses the first token. If separate tokens
> > are now needed for servers that previously shared the same token, then
> > the service has made a deliberate decision to increase security in a
> > way that wasn't backwardly compatible.
> >
> >> *This* would be the hack... If this is something people want to
> >> deploy, a full proposal end-to-end is required. And not now.
> > I few proposals have been made in the past. Some try hard to leave the
> > single token case alone, but always at a cost to complexity: eg the
> > first token needs to be handled differently to the other tokens.
> >
> >

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jun 2011 09:46:14 -0400

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-masked]>
> *To:* Phil Hunt <[email-masked]>; "Manger, James H" 
> <[email-masked]>
> *Cc:* OAuth WG <[email-masked]>
> *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?
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
> > Of Phil Hunt
> > www.independentid.com <http://www.independentid.com>
> > [email-masked] <mailto:[email-masked]>
> >
> >
> >
> >
> >
> > > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: David Recordon <[email-masked]>
Date: Fri, 17 Jun 2011 12:13:29 -0700

+1 Eran

On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>> preference,

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jun 2011 15:15:52 -0400

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:
> 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
>
>> 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?
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 Jun 2011 12:31:15 -0700

-1 on the reason not to discuss the issue now.

The current limited deployment case experience of OAuth does not necessarily indicate the expected use in the future. We already know it to be MUCH broader as the password anti-pattern is very large indeed.

I will also point out that this is a V. 2 specification. Thus now is not necessarily the time to artificially limit scope as it might be for a version 1 specification which may with good reason want to limit the use cases.

That said, *I do agree the idea is late in the V2 process*. If we can't develop a solid answer cleanly, and if it is too disruptive...we simply cannot pursue. Because of this, I want to have more discussion before dismissing the idea.

I am looking at potentially similar issues as previously raised by Torsten. My thoughts are:

The single-token schema may be fine for single-property cloud sites to go with the current single-token spec, but I'm sure multi-property sites will have these issues very quickly.

It also occurs to me that MAC tokens should have limited sharing of keys (e.g. to single client-server pairs), so that will tend to drive token services to want to issue more tokens then say with bearer tokens which could more easily be used in multi-property scenarios.  Of course, I haven't thought this through yet...this is just a top-of-the-head, what are the ramification thoughts.

I would like to see more discussion.

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 17 Jun 2011 13:02:21 -0700 (PDT)

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-masked]>
To: [email-masked]
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

>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!
>>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.
>>> >>> We have identified the need to request
              multiple tokens as one issue
>>> >>> that we would have to extend.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 Jun 2011 13:03:56 -0700

+1

Seems a reasonable approach/requirement.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-06-17, at 1:02 PM, William J. Mills wrote:

> 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
> 
>> 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 
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 17 Jun 2011 19:14:16 -0700

+1

OpenID Connect is a good example that adding it later is not that
difficult. In this case the other token is returned as a separate
parameter, which is much better IMO than an array.

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 18 Jun 2011 08:24:49 +0200

I assume you refer to the openid parameter. This parameter is not general purpose but problem specific. Thus it is in my opinion not suited as an example for a general purpose standard.

regards,
Torsten.

Marius Scurtescu <[email-masked]> schrieb:

+1

Marius
_____________________________________________

OAuth mailing list
[email-masked]