On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard <lshep...@facebook.com> 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. Agree we don't standardize the token. Disagree on supporting multiple AS. There is more to the web than the social web Luke, and supporting multiple AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. Having an optional parameter that would carry the token type from the AS to the PR would be useful and has been discussed in the past. Just like the access token, it could be opaque to the client. -- Dick -- Dick >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
