I don't see how the extra parameter is required to support multiple auth
servers for a resource.
Responses to Dick and Torsten:
On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
> if we have the parameter in the spec, then clients know to pass it along if
> they see it.
My main objection here is that the extra param requires more code on the
client. Even if it's an optional param, the client needs to worry about
multiple parameters, and that's annoying.
For example, here's the PHP code needed to make a resource request today (at
the end of the web server flow):
$access_token = oauth_get_access_token($_GET['code']);
$resource = file_get_contents('https://example.com/resource?oauth_token=' .
$access_token);
With this proposal, the client now needs to keep track of two parameters and
pass them both:
list($access_token, $format) = oauth_get_access_token($_GET['code']);
$resource = file_get_contents('https://example.com/resource?oauth_token=' .
$access_token . '&format=' . $format);
Why?
On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:
> 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.
It's not "magically" - the server just decodes the token and extracts any
useful information it's expecting. If it doesn't match the format it expects,
then it throws it away. Tokens will undoubtedly encode all sorts of useful
stuff that resource servers know how to decode - like format, expiration,
scope, whatever. The point is that the structure is undefined *to the client*.
For example, if the format is just encoded in the token, like this:
format=ubertoken&token=abcdefg
The protected resource request is then:
https://example.com/resource?oauth_token=format%3Dubertoken%26token%3Dabcdefg
and there's no extra code required on the client. Why is this not sufficient?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
