Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Janak Amarasena <janakama360@gmail.com> Mon, 01 June 2020 16:37 UTC

Return-Path: <janakama360@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0A3A0911 for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 09:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMJyavp4yIu8 for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 09:37:04 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2283A005C for <oauth@ietf.org>; Mon, 1 Jun 2020 09:37:04 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id l10so455481wrr.10 for <oauth@ietf.org>; Mon, 01 Jun 2020 09:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BSrIWfma8sp6ieEqn7qLhoPWAqVOlvAFwnv/toxE/oI=; b=mtH/AnDpuJjzmyQXqTx4XXoQPr7HVOqPJdRJa22oHZesiXnNyuQdtzIpGAOHNsJbT4 V2ESvf8Hms5G44GVBXutS0Z0XUuxAeYRI7LFXTRnV3fQBa9zmUqf+Ba/kWeZQdl4o+5q p+S1XwjSN0xgGvsjwAlWBQwuVpwfpiQC3hm3xfFxMkpyRoxjy8656UK5yrH4RXAPLuBi E/XzjQOwMGNHv88fNp+UKHj3USgIaFwvCNpxMGBUa4RPRxLE+AS/kzSI7opmayOg5ug5 1U+rTDI/2EnXr+rjAK2loEnXzJxeYuWIvtqBpX78Dczl9ttmI3eRlSy01E64sg9U2bNk rnpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BSrIWfma8sp6ieEqn7qLhoPWAqVOlvAFwnv/toxE/oI=; b=BWw7Bf9QbyLi5Ootc+V5NJX2Syp0nOSpfgHsKORNyDO9PIe5BLKOik/nWIhxXMzoa/ YbM13DZYOqM9sOo+awJJ8t+nFeMUv4m5c0TG3XFE+uI6zE5uwqcKprsfC1aknFaQUCPC sjlUxJt8tcE/HONIjxG4+KaNoaPM7RKlGKHmIHzZoTqi5tZEeKVp5+s2TxX/oPD9AIYZ OrWMV9iqHyb2a7aBWJvFTjDOch3s1CmLMmcA2rqgFz8HhNGcgJEruk0wngaglcukJ5Bf z2SCwfXnK91MeIjdX/VP4Vg5tKA2LhY0JKmafslAGInXNyFXfLRJCgb4g/ozsFODvSo4 yuuQ==
X-Gm-Message-State: AOAM5337nlB07uCpU6JHcV+s6k9pTgffjmLZ1i6SJGhTskWfLPNzNnqX H9ahjk06OZEUDsugek2CFvbCfyiZ1UXflPHk5tA=
X-Google-Smtp-Source: ABdhPJz/R4S/wLU2qtpF5T4wi9zIPxlejm01jS8Fvlm56TOIv5lUw2S9T6HgrrOHMVm/JjJLRQm3AHVeQuKT2AF1J20=
X-Received: by 2002:a5d:468d:: with SMTP id u13mr24245509wrq.73.1591029418939; Mon, 01 Jun 2020 09:36:58 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP8t4oVUpoqOFhb-Aft-5C4Z2F9O2vBxh6QxmkHrWkN_gw@mail.gmail.com> <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <e835def4-9688-112f-eadc-f645a303fa40@free.fr> <20200530205522.GV58497@kduck.mit.edu>
In-Reply-To: <20200530205522.GV58497@kduck.mit.edu>
From: Janak Amarasena <janakama360@gmail.com>
Date: Mon, 1 Jun 2020 22:06:22 +0530
Message-ID: <CAM7dPt1gKxmZB8DdFP55JWx=WnYRFvP+_fv+pU9SJn_JnYJ4rA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Denis <denis.ietf@free.fr>, oauth <oauth@ietf.org>, Vittorio Bertocci <vittorio.bertocci@auth0.com>
Content-Type: multipart/alternative; boundary="00000000000057d75c05a7086724"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NOGTTlNkO89_7F5XE1j_O3kE-IE>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2020 16:37:06 -0000

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 <kaduk@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
>