IETF Logo Mail Archive

[OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)

David Waite <david@alkaline-solutions.com> Mon, 05 August 2024 21:42 UTC

Return-Path: <david@alkaline-solutions.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 947C3C180B5A for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 14:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYRbglQb0Y8g for <oauth@ietfa.amsl.com>; Mon, 5 Aug 2024 14:42:50 -0700 (PDT)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29211C1654F2 for <oauth@ietf.org>; Mon, 5 Aug 2024 14:42:49 -0700 (PDT)
From: David Waite <david@alkaline-solutions.com>
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com
Message-Id: <66684D87-21C4-4FAC-8B40-401B6FA0F5C9@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E1AD599-28B7-4440-882C-4220A0CDF369"
Mime-Version: 1.0
Date: Mon, 05 Aug 2024 15:42:36 -0600
In-Reply-To: <DBAPR83MB04370C7F73A28363E06501D291BE2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
To: Pieter Kasselman <pieter.kasselman=40microsoft.com@dmarc.ietf.org>
References: <20240731132617.0FE6C3B873@rfcpa.rfc-editor.org> <CA+k3eCSU45mnmRQxdNhf-cJ6FEfxon9d64bO0jJ4u3G99bEvqA@mail.gmail.com> <DBAPR83MB0437A90177CB7B34DBD67F1291B12@DBAPR83MB0437.EURPRD83.prod.outlook.com> <CA+k3eCQ_8NAmdYejmj7oLW=QeLM1=AHKnPQyM2qhc65=hNwqTw@mail.gmail.com> <CAGL5yWYde01JQYc5h4iESgQG=rRNGBREbKDD3U3oYvNHH4VG9Q@mail.gmail.com> <DBAPR83MB043762B970631E79DACA729191B22@DBAPR83MB0437.EURPRD83.prod.outlook.com> <CA+k3eCS7x9p0ZB5J7hu0=TkWt1kuFzgQQO979ViJ0qnFUXfAdA@mail.gmail.com> <DBAPR83MB04370C7F73A28363E06501D291BE2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
X-Spamd-Bar: --
Message-ID-Hash: VUCMEFD7E75ER5QWR2KJA4H57ZBMAYZI
X-Message-ID-Hash: VUCMEFD7E75ER5QWR2KJA4H57ZBMAYZI
X-MailFrom: david@alkaline-solutions.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "prkasselman@gmail.com" <prkasselman@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qqode_V8PEaM3vYp2OFEkZEj4Eg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>


> On Aug 5, 2024, at 1:52 PM, Pieter Kasselman <pieter.kasselman=40microsoft.com@dmarc.ietf.org> wrote:
> 
> I tried to keep the changes to additional text that would scope the processing rules more precisely for the JWT/JWS/JWE cases (point 7 in the processing steps references JWS and JWE separately, so thought I would propose text that does something similar to that). The idea of additional text is that a reader who is familiar may find it easier to process the delta.
>  
> However, if we want to change the text, I like your second option:
>  
> "Verify the resulting JOSE Header according to RFC7515 or RFC7516."
>  
> I don’t think we should delete the bullet completely.
>  
> Cheers
>  
> Pieter

I prefer this over the current text, which might be incorrectly construed to provide counter guidance to the “crit” protected header parameter.

-DW

v2.26.15 | Report a Bug | By Email | System Status