Subject: [OAUTH-WG] VOTE: Token type response parameter

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 16 Nov 2010 18:32:46 -0700

The new draft will include a new token_type response parameter. In my original proposal I suggested making this an optional response parameter with a default value of 'bearer' or 'plain' to keep existing -10 implementation compliant with -11.

Options are:

1. Missing type response parameter means bearer token
2. Missing type response parameter means whatever the service default token type is
3. Servers must include an explicit token type with each response, where each token spec (bearer, signed, etc.) register their own type name
4. No token type. Type is determined by other attributes (such as secret and hash algorithm name).

#1 and #3 are the most consistent with current design and best for interop. #1 requires no changes to -10 code, but leads to ugly spec organization (it links the bearer token spec with the framework spec).

I'm strongly in favor of #3 as existing clients will ignore this and just assume bearer. Any server introducing a new token type will need to change clients anyway. Servers will need to be changed to add the new parameter but that's a trivial change (and -11 includes some normative changes already - all minor).

So +1 on #3 for me.

Please register your preference.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Nov 2010 00:50:03 -0700

Nothing? No one cares?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, November 16, 2010 5:33 PM
> To: OAuth WG
> Subject: [OAUTH-WG] VOTE: Token type response parameter
> 
> The new draft will include a new token_type response parameter. In my
> original proposal I suggested making this an optional response parameter
> with a default value of 'bearer' or 'plain' to keep existing -10 implementation
> compliant with -11.
> 
> Options are:
> 
> 1. Missing type response parameter means bearer token 2. Missing type
> response parameter means whatever the service default token type is 3.
> Servers must include an explicit token type with each response, where each
> token spec (bearer, signed, etc.) register their own type name 4. No token
> type. Type is determined by other attributes (such as secret and hash
> algorithm name).
> 
> #1 and #3 are the most consistent with current design and best for interop.
> #1 requires no changes to -10 code, but leads to ugly spec organization (it
> links the bearer token spec with the framework spec).
> 
> I'm strongly in favor of #3 as existing clients will ignore this and just assume
> bearer. Any server introducing a new token type will need to change clients
> anyway. Servers will need to be changed to add the new parameter but
> that's a trivial change (and -11 includes some normative changes already - all
> minor).
> 
> So +1 on #3 for me.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: prateek mishra <[email-masked]>
Date: Thu, 18 Nov 2010 09:31:52 -0500

+1 on #3

from an enterprise perspective, we really dont want applications/clients 
to have embedded knowledge of the security model for any target resource.

As I understand this proposal, this would allow a security component at 
the client site/device to discover and create the right type of token 
(bearer/hok, SAML,/JSON) and then bind it appropriately to the resource 
request.

- prateek

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Nov 2010 09:38:20 -0500

I would prefer something like #3, but I think #2 is the most practical
as it keeps the spec mostly hands-off and doesn't put the weight of one
token type above another -- it keeps the kind of token opaque to the
"get a token" part of the scheme. 

#4 is a major fail though.

 -- justin

---

From: William Mills <[email-masked]>
Date: Thu, 18 Nov 2010 07:27:36 -0800

#3.  It's clear and well defined.  No chance of confusion.

> > 3. Servers must include an explicit token type with each response,
> where each token spec (bearer, signed, etc.) register their own type
> name

---

From: George Fletcher <[email-masked]>
Date: Thu, 18 Nov 2010 11:07:23 -0500

+1 for #3 for me as well

---

From: Todd W Lainhart <[email-masked]>
Date: Thu, 18 Nov 2010 11:17:22 -0500

#3

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:
Eran Hammer-Lahav <[email-masked]>
To:
OAuth WG <[email-masked]>
Date:
11/18/2010 02:50 AM
Subject:
Re: [OAUTH-WG] VOTE: Token type response parameter
Sent by:
[email-masked]

Nothing? No one cares?

EHL

---

From: Lukas Rosenstock <[email-masked]>
Date: Mon, 22 Nov 2010 15:26:40 +0100

I'm all for #3.

#1 will just restart the discussions about "OAuth preferring bearer"
so better drop it.
#2 and #4 are bad for interoperability and extensibility.