1. ++ 2. ++ 3. ++ 4. ++ as a part of 3., otherwise -- -- justin
On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 should not prohibit resource owners supporting multiple > Authentication Servers > 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional > parameter that is opaque to the client but identifies the "token format" > > Thanks, > George > > On 6/4/10 12:45 PM, Luke Shepard wrote: > > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > > > > > >> 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. > >> > > Whoa, I didn't say there wasn't. I agree that supporting multiple > > authorization servers is a reasonable design goal and there are some people > > who are making that work. > > > > I was just pointing that that a common case, today, is to have a single > > authorization server for a given resource - I mentioned several examples of > > services that work this way now. OAuth 2.0 needs to support that use case > > in a clean way.= > > > > > _______________________________________________ > 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
