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
