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
