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". 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
