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