Am 04.06.2010 19:45, schrieb John Kemp:
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
#4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in the main
spec. and giving it a default value, and semantics of "opaque" for when it
isn't present (ie. the current case). That explicitly allows other specifications to use
the attribute, and is then good for future interoperability (and also future
backwards-compatibility)
there is another point: such a parameter could be used to let the
authorization server indicate the format of the access token to the
resource server. This will help deployments with more than one token
format in use. For example, we use SAML and another proprietary format.
Without such a parameter, the resource server has to somehow (magically)
find out the format of the incomming token.
From my point of view, #4 should happen now independent of #3.
regards,
Torsten.
- johnk
On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher<gffle...@aol.com> 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
_______________________________________________
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
