+1 for an optional "token_format" attribute/parameter

Am 04.06.2010 17:21, schrieb John Kemp:
Hi Luke,

On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:

On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:

On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent auth 
servers is not in scope for OAuth. That said, there's nothing to stop multiple 
servers to agree amongst themselves to have a standardized format for access 
token- and if necessary, to write that agreement as a separate spec (perhaps an 
extension).
-1

limiting OAuth to a single Authorization Server (AS) and it's associated SPs 
(resource owners) significantly restricts the value of delegation across the 
internet.

I'm not saying that we need to limit it just to that circumstance, but the 
single-server scenario is one of the most common use cases for OAuth - for 
example, Google, Flickr, Facebook, Yahoo, Twitter all generally support tokens 
that only work on their own services. I've listed one reason why a formalized 
structure would be bad for Facebook (token size would increase).

We should solve one problem at a time. It's easy to layer structure on top of 
an opaque blob in a separate spec. The question to ask is, if a provider chose 
NOT to support whatever standardized token format that came up, would they 
still be able to use the OAuth 2.0 flows? If the answer is yes, then it belongs 
in a different spec.
I think that even if specific token formats are defined in separate specs. 
(which I agree with) you would still need to define a standardized optional 
attribute to carry the format description reference.

What is wrong with agreeing in OAuth itself to do that much - define an optional attribute called 
"token_format" which MAY be present, and if so MUST be passed on by the client? If the 
format attribute is not present, it's value has default semantics of "opaque"? Other 
specifications may then define additional format values and describe in more details what they mean.

Regards,

- johnk

_______________________________________________
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

Reply via email to