[OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Francesca Palombini via Datatracker <noreply@ietf.org> Sun, 04 April 2021 18:01 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD873A1313; Sun, 4 Apr 2021 11:01:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francesca Palombini via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, hannes.tschofenig@arm.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Francesca Palombini <francesca.palombini@ericsson.com>
Message-ID: <161755926036.31657.529017576412672874@ietfa.amsl.com>
Date: Sun, 04 Apr 2021 11:01:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iLnoaVPYxmpPYMbKuJ-WEV5tiFs>
Subject: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 04 Apr 2021 18:01:01 -0000
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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. Please find some comments and clarifying questions below. Francesca 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 introduction. 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 https://www.rfc-editor.org/rfc/rfc7515.html#section-9.2.1 ? 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.
- [OAUTH-WG] Francesca Palombini's No Objection on … Francesca Palombini via Datatracker
- Re: [OAUTH-WG] Francesca Palombini's No Objection… Vittorio Bertocci
- Re: [OAUTH-WG] Francesca Palombini's No Objection… Brian Campbell
- Re: [OAUTH-WG] Francesca Palombini's No Objection… Francesca Palombini