Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Vittorio Bertocci <> Wed, 14 April 2021 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76F7B3A11DE for <>; Wed, 14 Apr 2021 00:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fmD_edFY8xpt for <>; Wed, 14 Apr 2021 00:18:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D1893A1167 for <>; Wed, 14 Apr 2021 00:18:56 -0700 (PDT)
Received: by with SMTP id p67so8187315pfp.10 for <>; Wed, 14 Apr 2021 00:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=PJaQ9eTa+/inRNEiB/Wg3tmXKBVCnemTH7nzL2leqr8=; b=dlAw0O1h0ndyiqbK7nNXXz1uEbZV13icQGrTOJ60e9PJL0cV1RblzYWUu8ZmL/7l1X F3nx7N6yHL31PoD/naKdefthtTu8CIaY67uySvdJZAMAyOw5xf+sXhJMEa67OcwVj38V O1z7RFr1jdqodrOe3AyUPlsWCqhqyUWaP4MbnF13RwXwnfvH0eQs0e13Z+Di+QeVT2sP oJjz0wcrSVzQOgb+0bPH9r4Ek2cn7MtjKHP/s3zhr2Cd2iQ0zZo6e5VKiuJFsiBNfe5K qhpJREpxuzpHV3c8gVhugEb+e/X3ZcSYdMSiXxJL0L+RMpojnIbyQ7WjjH4DFWgUXAM+ qBXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=PJaQ9eTa+/inRNEiB/Wg3tmXKBVCnemTH7nzL2leqr8=; b=FRMzYTbQWFj7KT9TktfaipoqYOS0BfJVNX1HtFeVU9NYlJtZ1WuB/Fw0HAMWf8ZLHp cq3tXWwAu59E2h+CEuLxMIb2tlVIrUPWkWf6H4DLeq6oWDqA0weeD9fmncAznSBc+P6Y e5h4bvquHy5ppnJTREtb9LS9qmCyVrXr3N8Y70WMdsrfn3Sv9RVY8V/uqztN06WiakwZ upDE1iV5UNG59Gze01AfnUXhPpfULyYFCKVABnwOV9OPc7P+tAhKlnmu1ZuEiO7N30n9 GUuum9MEckK5KiWo702k3NCs4dE1zn2WSjj2NKfHpu2d8jGJ8/9RiSoiOLFbGANaUxPR WCtw==
X-Gm-Message-State: AOAM533nvESGX7zK8gAuJQROnbek8I42wgiRC3bdAwMfWuV90MOCmDiG b6F/efI0yx2upNeqghIEFL3kQw==
X-Google-Smtp-Source: ABdhPJxDeyzefJ6IK2VMZQfpeioo80qKzB4gluNBPnoG9FcA3M+GSoT7QOIfjE5SbKf9Ml+RZzRg/w==
X-Received: by 2002:a65:4303:: with SMTP id j3mr35595007pgq.55.1618384735315; Wed, 14 Apr 2021 00:18:55 -0700 (PDT)
Received: from ([2603:1036:301:402a::5]) by with ESMTPSA id k22sm14213072pfa.93.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 00:18:54 -0700 (PDT)
From: Vittorio Bertocci <>
To: Francesca Palombini <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Thread-Index: ATQxMDY21bw61opi7lXBW2kIpARnpcX/nG17
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 14 Apr 2021 07:18:54 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Apr 2021 07:19:06 -0000

Hi Francesca,
Thanks for your review and thoughtful comments!
Comments below.

>    1. -----
>    [...]
While it is reasonable to expect that a RS receiving an unencrypted token after requesting it to be encrypted will reject it, there are a number of cases where the RS might elect to do otherwise. For example, the solution might be already working in production: the encryption requirement might be an improvement that is still propagating thru the system, and there might still be access tokens cached in clients that the RS might still be willing to accept to guarantee business continuity. "SHOULD" gives a strong signal to implementers of what the desired behavior is, but leaves them some freedom to accommodate situations like the aforementioned one.

> 2. ---
> [...]
Fair enough. I added the following text at the beginning of 2.1. Thanks for catching this.
     JWT access tokens MUST be signed. Although JWT access tokens can use any signing algorithm[..]
This change will appear in the next revision, which I will post soon.

>     3. -----
> [...]

Formally, I agree that JOSE would also work. The choice of media type derives from There is no functional difference between JWS and JWE in the intent a client has when calling an RS, here there's not much to be gained in using different MIME types for those cases. Furthermore, whereas developers are familiar with the term "JWT", both from direct use and thanks to the popularity of OpenID Connect (which does use application/jwt), terms like JWS, JWE or JOSE wouldn't be as promptly understood as JWT. Throughout the discussions in the last couple of years, the consensus on the use of at+jwt was solid- my hope is that will make intuitive sense for implementers, too.

On 4/4/21, 11:01, "Francesca Palombini via Datatracker" <> wrote:

    Francesca Palombini has entered the following ballot position for
    draft-ietf-oauth-access-token-jwt-12: No Objection
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    Please refer to
    for more information about IESG DISCUSS and COMMENT positions.
    The document, along with other ballot positions, can be found here:
    Thank you for the work on this document. Please find some comments and
    clarifying questions below.
    1. -----
          registration.  If encryption was negotiated with the authorization
          server at registration time and the incoming JWT access token is
          not encrypted, the resource server SHOULD reject it.
    FP: Why is this just SHOULD and not MUST? In which case does it make sense to
    accept a non-encrypted token when encryption was negotiated?
    2. -----
    Section 2.1:
       Section 4).  JWT access tokens MUST NOT use "none" as the signing
       algorithm.  See Section 4 for more details.
    Section 4:
       For the purpose of facilitating validation data retrieval, it is here
       RECOMMENDED that authorization servers sign JWT access tokens with an
       asymmetric algorithm.
       o  The resource server MUST validate the signature of all incoming
          JWT access tokens according to [RFC7515] using the algorithm
          specified in the JWT alg Header Parameter.  The resource server
    FP: It might be obvious, but I think it would be useful to have an explicit
    sentence stating that JWT MUST be signed. The quoted text from Section 2.1 seem
    to imply it. Section 4 only RECOMMENDS that the JWT is signed with and
    asymmetric algorithm. Later on, Section 4 implies that all JWT are signed. On
    the other hand I note that encryption can be negotiated (and is optional) from
    the followig point; in that case it is not clear that the token is still signed
    (so the nested JWT would be a JWE nested in a JWS), or only JWE is used. What I
    am looking for is simple clarifications to be added for example in the
         o  If the JWT access token is encrypted, decrypt it using the keys
          and algorithms that the resource server specified during
          registration.  If encryption was negotiated with the authorization
    3. -----
    On the same note, and depending on the previous answer, why is the media type
    registered and used "application/at+jwt" and not something like
    "application/at+jws"/"application/at+jwe" or rather "application/at+jose" to be
    compliant with ? I
    think that the structure transported is in fact a JWS or a JWE, rather than the
    JWT, and if that's the case that should be made clear in the text (one example
    where this could be clarified is in the following sentence)
       Resource servers receiving a JWT access token MUST validate it in the
       following manner.