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

Reply via email to