(resending to DL due to apparent DL failure over the weekend... I know Dick
and Luke already received my email because they were individual recipients
as well... I don't know if the DL received their replies or not)...
Great discussion, all. I am also for an optional parameter that's part of
the main spec, and defining possible structures for the access token in
separate specs.
But *token_format* is not the idea I think. It's more like *token_origin.
*The scenario I had in mind was that a RS actually accepts access tokens
from two auth servers, both tokens are in the *same* format, but the RS
needs to know which public keys to apply while verifying signatures and
decrypting the token in order to complete it successfully. Now, an AS
identifier *could* be encoded directly into the access token to help the RS
know, which is fine if everyone was coordinating their design together. But
if you have two auth servers issues encrypted access tokens in different
formats, it gets *much* harder for the resource server to decide how to
decrypt, verify, and decode the access token. As the number of auth servers
supported by a RS goes up, the trial-and-error approach gets progressively
worse.
The only way I can see to avoid this is for an OAuth 2.0 specified standard
to exist so that all auth servers provide a way for RS to know "ok, this
access token came from *x*, so I'll decode it this way..."
So to recap, *knowing just the format is insufficient, *since that doesn't
tell you the public keys to use. Including the public keys in the token
itself will significantly increase the size of the token, and assumes again
that the RS knows how to pull it out in advance of decoding it.
Chicken-and-egg problem.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Fri, Jun 4, 2010 at 6:58 PM, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> 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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
