+1 (just in case that was not clear from my other emails :) On 2010-06-04, at 8:57 AM, Torsten Lodderstedt wrote:
> +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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
