On 2010-06-04, at 6:39 PM, Luke Shepard wrote:
> I don't see how the extra parameter is required to support multiple auth
> servers for a resource.
it is needed if there are multiple token types
>
> 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?
The client would only need to do that if the AS will issue the parameter. I
would expect that libraries would deal with the two parameters. Moving an extra
one around does not seem to be hard.
>
> 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*.
what if there are multiple token formats? that is were the magic comes in.
Detecting format can be tricky.
>
> 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?
one token could be SAML, another JSON in one format, another in URL encoded
name/value pairs. The PR is having to detect both syntax and semantics.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
