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. > On the other hand, if OAuth allows for cross AS token processing, then it > becomes very easy for me to protect my photo album while not requiring that > all those I've shared it with to have an account at my photo service (as one > example; there are many more). There is a lot more that would need to happen to support this outcome than merely standardizing the format of the token. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
