On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote: > Hi all, > > My apologies, if this was already discussed. > > In section *4*. Validating JWT Access Tokens > <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07#section-4> > it > is stated; > > The resource server MUST handle errors as described in section 3.1 of > [RFC6750] <https://tools.ietf.org/html/rfc6750#section-3.1>. In > particular, in case of any failure in the validation > checks listed above the *authorization server* response MUST include > the error code "invalid_token". > > > > > Should this be; > > ... above the *resource server* response MUST include the error code > "invalid_token".
It does look like it should be the resource server there, yes. Good catch, and thanks for mentioning it! -Ben > > If that is not the case, which kind of scenarios would occur for an AS to > respond with the error code "invalid_token"? > > Best Regards, > Janak Amarasena > > On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk <ka...@mit.edu> wrote: > > > On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: > > > Hi Benjamin, > > > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: > > > >> Since then, I questioned myself how a client would be able to request > > an > > > >> access token that would be > > > >> *strictly compliant with this Profile*. > > > > I don't understand why this is an interesting question to ask. The > > access > > > > token and interpretation thereof is (AIUI) generally seen as an > > internal > > > > matter between AS and RS, with the client having no need to care about > > the > > > > specifics. > > > > > > This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not > > > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. > > > > Sure. But (in my understanding), in common usage, the contents and > > interpretation of the access token is set by common agreement between AS > > and RS, with the client serving only as a "dumb" channel for transporting > > the token. That is, we're providing a token format that an RS and AS can > > agree to use, most likely for all tokens issued by the AS for that RS. I > > don't know of any existing mechanisms, or desire for such mechanisms by > > deployments, for using a different token format for different tokens issued > > by a given AS for a given RS. Attempting to have the client provide input > > that would affect such a mechanism seems like complexity with no market > > demand; a "solution in search of a problem" as it were. Is there some > > pent-up demand among OAuth deployments that I'm not aware of? I freely > > admit to not being very on top of the broad spectrum of what's deployed... > > > > > 1) A client may wish to obtain an Access Token that corresponds to this > > > Profile because, for example, > > > this document mandates the "sub" claim to be present". Hence, the > > > content of the Access Token is not > > > totally "/an internal matter between AS and RS/". > > > > > > However, I have not understood how a client could request an Access > > > Token that corresponds to *_this_***Profile, > > > since there is no mandatory parameter in the request (both the "scope" > > > parameter and the "resource" parameter are optional). > > > > > > In the future, we could define _*another*_**Profile. Hence, there is the > > > same question: How could a client request an Access Token > > > that corresponds to *_that other_***Profile ? > > > > > > 2) When getting a JWT, how can the client make sure that the access > > > token it got is compliant with this Profile ? > > > > > > RFC 8725 states in section 3.11 : > > > > > > 3.11. Use Explicit Typing > > > Sometimes, one kind of JWT can be confused for another. If a > > > particular kind of JWT is subject to such confusion, > > > that JWT can include an explicit JWT type value, and the validation > > > rules can specify checking the type (...). > > > Explicit JWT typing is accomplished by using the "typ" Header > > > Parameter. > > > > > > Wouldn't be wise to include an explicit JWT type value for JWTs > > > conformant to this Profile ? > > > > In the model where the client is a "dumb" communications channel, this > > question does not seem interesting. But the related question of "how can > > the RS make sure that the access token it got was generated according to > > this profile?" does seem interesting, and seems like it would benefit from > > the same proposed solution. > > > > > This relates to an email posted by Dominick Baier under the topic "JAR: > > > JWT typ" on May 19 : > > > > > > This has been brought up before - but no response. > > > > > > Either I can’t find it - or it is missing. But is the setting the > > > JWT typ explicitly mentioned somewhere? > > > > It is fairly likely that I will remember to ask about explicit "typ" usage > > if I'm still on the IESG when this document gets there: I think I've been > > making a habit of doing so. > > > > Thanks, > > > > Ben > > > > _______________________________________________ > > 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
