[OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD-JWT architecture feedback)
Dick Hardt <dick.hardt@gmail.com> Tue, 24 September 2024 17:18 UTC
Return-Path: <dick.hardt@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 3CA1DC17C8B3 for <oauth@ietfa.amsl.com>; Tue, 24 Sep 2024 10:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NtPHDozTdRL for <oauth@ietfa.amsl.com>; Tue, 24 Sep 2024 10:18:38 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8144FC169411 for <oauth@ietf.org>; Tue, 24 Sep 2024 10:18:23 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e24a2bc0827so452253276.2 for <oauth@ietf.org>; Tue, 24 Sep 2024 10:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727198302; x=1727803102; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3pmmszDvx/hns2ityRMuGCrm2derephlCNezeogO5pg=; b=jNWCSlPtW1nzH2n5uqUhdOri1B79CFr28nN6CuLLpIGzD5AxWXEj4NijeJyBZoRCSO TD/I7H0KV+utaPkVvO+APdCbzYlg0ZqbDWyEivq8Vuj5q89ixiyA7wzIKQiUvOnnzEW/ IuMWlQxktHdvv5a+jZPChpuUKOA2aFVKiXA/Tu+NTdU1ohY1Ok8NUxF6jI+K/0IbrUh7 rjZmPAAR8RwS+ymet+ThRoUEs7r7FHYewfalHFBCMNOIInmEusvQOhLiWwc/2jIqEtR9 Qg5ZTNncUO6jnseY7kGGRihnoFl2Swa8UZvdAarnNcv0OTchr/+Mxb/Pk2Fz8I10JENb qfPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727198302; x=1727803102; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3pmmszDvx/hns2ityRMuGCrm2derephlCNezeogO5pg=; b=eGVdgSB5UIrbyi5Pkl6BMM5/NbWdEZmbw/hyS+sxAbpxLf8h1f3rPBmqiOkBAPNxvH pfHhxTx0CzS8Zk/+dw8jD3cLYnF5djm6Q+ylkIdvL0Gq3T12PsCS/nYIt411jZmO6/hp O9dwZmmIbnwkWR1Yj6cKfvTQOT6kUDPcNrDhIvSK0H73bCDLYno5NmdIsV2oKz259zoU cBtd3n3V3ioaaT0H5zki5Y+DkfuvMjpXGYNNzsmAEF/UEL2cpHVAC557Rf3ZRzM4KLMT W1qBLHg5a9tlLYVAUC1eGQZz5hgxp4G+gny42ap0tTQMrTv5355ySXBq4Znz70X1gtlu 9iWQ==
X-Forwarded-Encrypted: i=1; AJvYcCVsDgL+aHuInkbtRFGmZOyJx258QohT+Abf0AG7RDlH5suKv1UIeOtvHi0Z+8og/I3a7PRSQg==@ietf.org
X-Gm-Message-State: AOJu0YxsNm4snB6QcNiqJ+HdN5UGr4iLS41bcgBJIhJPk2QWwlSIxBDE 0JCPPT0K+z2WtxhiD+bjkrgipky969pKTUsRpca8rkK2N27USwTaIK0h9WWPhdlHWFiQcQ4Ic7F gr37ef8GIdDWsM9CHdDwpEcX1US+unzp3hCQ=
X-Google-Smtp-Source: AGHT+IGww3jJKjrclttmcph15je89V/+siSoYqb5pUyMxHvDYRTnLKD4xPByNfnbu2nnmVWsvHU/UBr8/hMu2O8uYjM=
X-Received: by 2002:a05:6902:e8e:b0:e11:6ae6:1bde with SMTP id 3f1490d57ef6-e2252f56043mr10510634276.31.1727198302337; Tue, 24 Sep 2024 10:18:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-s9kricU8_VBBucQMob-n1jWN5xHd5Ymck=biUWqpH9yQ@mail.gmail.com> <e64eb21d-1ef4-4352-9c74-ffbb853ce3da@danielfett.de> <CAD9ie-t9jLMG5aROCR-EOuCYh19F2r67-C0Puw2OF4GEcvBc2g@mail.gmail.com> <SJ0PR02MB7439E7A8C62588FB6BBABA97B76D2@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAD9ie-tOsd3wM6mXNFWqd-UNMG-4GaMCiZQ7H6Xw_5JNUrGQPA@mail.gmail.com> <CA+k3eCRJbTA6qcKzK0xAQA2Xv2jVFHyPb=pVnpoJTy0sMXCJog@mail.gmail.com>
In-Reply-To: <CA+k3eCRJbTA6qcKzK0xAQA2Xv2jVFHyPb=pVnpoJTy0sMXCJog@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 24 Sep 2024 18:17:45 +0100
Message-ID: <CAD9ie-vJMTvjdR2WaSFLqbMRYjoNB0iFq+Vz0DdV-V2bf1=LXg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="0000000000004486e40622e0b175"
Message-ID-Hash: OIM6LIAO4NWAJYTSU2CGGE4D3LJZAJR7
X-Message-ID-Hash: OIM6LIAO4NWAJYTSU2CGGE4D3LJZAJR7
X-MailFrom: dick.hardt@gmail.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: "oauth@ietf.org" <oauth@ietf.org>, "kristina@sfc.keio.ac.jp" <kristina@sfc.keio.ac.jp>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: Dick.Hardt@gmail.com
Subject: [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD-JWT architecture feedback)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lNxNvEXjTtb-qzUjgR3Xeiq1tcg>
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>
Sorry Brian, I'll try again. In the current text: SD-JWTs are also potentially vulnerable to such confusion attacks, so it is RECOMMENDED to specify an explicit type by including the typ header parameter when the SD-JWT is issued, and for Verifiers to check this value. It is only RECOMMENDED to explicitly type. My suggestion is that a SD_JWT MUST have "typ" in the header, and be specific about what that value is, and how other applications that require additional typing do it. You sort of have that with When explicit typing is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT. But once again it is a RECOMMENDED and not a MUST -- and it is confusing. As an implementer, am I allowed to use "application/sd-jwt" or just "sd-jwt" -- or do I have to come up with my own value for "example". Given other threads, it is now clear to me (which it was not earlier) that the authors view this as a base document that will be built upon in other documents -- so perhaps you are just giving general guidance here. But as I expressed in the other thread, I suspect many people will just read this doc and do what it suggests, hence let's make explicit typing a MUST. FWIW: the "typ" header property was intended to help a processor know how to process the rest of the dot separated components. The initial use cases being something signed vs encrypted. On Tue, Sep 24, 2024 at 5:17 PM Brian Campbell <bcampbell@pingidentity.com> wrote: > I must admit that I'm finding it difficult to fully grasp the points > you're making on this topic.. As with the other topics, there has been > extensive discussion about typing and media types[1]. And, while I have my > own reservations about using something inside a thing to say what the thing > is and the ascension of that questionable mechanism to "best" practice[2], > the SD-JWT document explicitly cites and follows the guidance on explicit > typing[3] from the JWT BCP that bears your name as an author[3']. The > citing of that very section in asking "Why leave the typing in the header > to be determined by the application (10.11), and not just be 'sd-jwt' and > be REQUIRED"[4] seems incongruent and leads me to wonder if maybe there's > been some misunderstanding and/or miscommunication somewhere in all this. > > The document does plan to request registration of an "application/sd-jwt" > media type to be used wherever media types might be used "indicate that the > content is an SD-JWT." As such, one could certainly use "typ":"sd-jwt" in a > SD-JWT header. But I don't see the utility in doing so and feel it would be > a throwback to the now largely seen as flawed suggestion in JWT that > "typ":"JWT" be used to say that the JWT is a JWT. > > [1] a sampling of such discussions that I think have been referenced > previously but are relevant nonetheless: > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267 > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327 > > [2] one small diatribe on the topic > > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327#issuecomment-1736438782 > > [3] The Explicit Typing section in SD-JWT (10.11) > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-12#section-10.11 > <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-explicit-typing> > > [3'] RFC 8725 aka BCP 225 aka JSON Web Token Best Current Practices > https://datatracker.ietf.org/doc/rfc8725/ > > [4] SD-JWT architecture feedback received several days after the close of > WGLC > https://mailarchive.ietf.org/arch/msg/oauth/412IiUprR9YbXNfEGfSXVVx_pzk/ > > [5] Media Type Registration in the draft > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-12#section-13.2 > > [6] the "typ" (Type) Header Parameter in JWT > https://datatracker.ietf.org/doc/html/rfc7519#section-5.1 > > On Sun, Sep 22, 2024 at 8:15 AM Dick Hardt <dick.hardt@gmail.com> wrote: > >> I am trying to make a few points. My reference to the BCP was on the >> recommendation to do explicit typing. I'm suggesting that the sd-jwt >> document state that include "typ" is a requirement, and to be explicit in >> what that value should be. >> >> I would suggest that value be "sd-jwt" >> >> The "application+" mechanism was already deployed when we wrote the BCP >> -- too late to change that. But sd-jwt is a new token format and can learn >> from implementation challenges in the past. >> >> >> >> On Sat, Sep 21, 2024 at 9:17 PM Michael Jones < >> michael_b_jones@hotmail.com> wrote: >> >>> Actually, the JWT BCP (which we were both authors of) does not recommend >>> using a single media type. Rather, it recommends using a specific >>> media type suffix in the “typ” values >>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing>: >>> >>> When explicit typing is employed for a JWT, it is *RECOMMENDED* that a >>> media type name of the format "application/example+jwt" be used, where >>> "example" is replaced by the identifier for the specific kind of JWT. >>> >>> >>> >>> SD-JWT is doing the same thing, recommending the use of the media type >>> suffix “+sd-jwt”. >>> >>> >>> >>> This enables more fine-grained explicit typing. For instance, when >>> doing explicit typing for an SD-JWT in the Example use case, the “typ” >>> value would be “example+sd-jwt”. This can then be distinguished from an >>> SD-JWT for the Other use case, which would use the “typ” value >>> “other+sd-jwt” – meeting the goal of explicit typing. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* Dick Hardt <dick.hardt@gmail.com> >>> *Sent:* Saturday, September 21, 2024 9:16 AM >>> *To:* Daniel Fett <mail@danielfett.de> >>> *Cc:* oauth@ietf.org; kristina@sfc.keio.ac.jp >>> *Subject:* [OAUTH-WG] Re: SD-JWT architecture feedback >>> >>> >>> >>> … >>> >>> >>> >>> *Explicit Typing* >>> >>> Why leave the typing in the header to be determined by the application >>> (10.11), and not just be 'sd-jwt' and be REQUIRED? >>> >>> We had extensive discussions around typing, please refer to the >>> following issues: >>> >>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267 >>> >>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327 >>> >>> - https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/345 >>> >>> >>> >>> Those issues don't really address the point. >>> >>> >>> >>> Per RFC 8725: JSON Web Token Best Current Practices (rfc-editor.org) >>> <https://www.rfc-editor.org/rfc/rfc8725.html#name-use-explicit-typing> -- >>> the best practice would be to have a single type that would allow a library >>> to know it is an SD-JWT. If additional context is needed, perhaps that >>> should be a different header property? >>> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*
- [OAUTH-WG] SD-JWT architecture feedback Dick Hardt
- [OAUTH-WG] Re: SD-JWT architecture feedback Warren Parad
- [OAUTH-WG] Re: SD-JWT architecture feedback Daniel Fett
- [OAUTH-WG] Re: SD-JWT architecture feedback Dick Hardt
- [OAUTH-WG] Leading underscores in SD-JWT Claim Na… Michael Jones
- [OAUTH-WG] Explicit typing of SD-JWTs (was SD-JWT… Michael Jones
- [OAUTH-WG] Re: Leading underscores in SD-JWT Clai… Dick Hardt
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Dick Hardt
- [OAUTH-WG] Re: Leading underscores in SD-JWT Clai… Rohan Mahy
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… David Waite
- [OAUTH-WG] Re: SD-JWT architecture feedback Rohan Mahy
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Rohan Mahy
- [OAUTH-WG] Re: SD-JWT architecture feedback Dick Hardt
- [OAUTH-WG] Re: Leading underscores in SD-JWT Clai… Brian Campbell
- [OAUTH-WG] Array Disclosure (was SD-JWT architect… Denis
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Kristina Yasuda
- [OAUTH-WG] Re: SD-JWT architecture feedback Brian Campbell
- [OAUTH-WG] Re: SD-JWT architecture feedback Dick Hardt
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Brian Campbell
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Dick Hardt
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Brian Campbell
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Dick Hardt
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Rohan Mahy
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Brian Campbell
- [OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD… Dick Hardt