[OAUTH-WG] Re: Leading underscores in SD-JWT Claim Names (was SD-JWT architecture feedback)

Dick Hardt <dick.hardt@gmail.com> Sun, 22 September 2024 14:13 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 510BBC151995 for <oauth@ietfa.amsl.com>; Sun, 22 Sep 2024 07:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, 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 Pl7rNeI1tbcN for <oauth@ietfa.amsl.com>; Sun, 22 Sep 2024 07:12:56 -0700 (PDT)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 6F817C15106C for <oauth@ietf.org>; Sun, 22 Sep 2024 07:12:56 -0700 (PDT)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-6dbc5db8a31so25148397b3.1 for <oauth@ietf.org>; Sun, 22 Sep 2024 07:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727014375; x=1727619175; 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=moknVuz5lyC5Ycb1Ux95VyjnWgGb3KsUBQVvJ5nf//s=; b=RfzcIQobcOMi1MNMXYnNoCgm95z+6vNAmf/bMHtB1UqnuJ6+L9Lu22oB5jkfeiEoT+ B0KXLj0KcZ4GUNPzaQYIozWjHQZqX4CclIE3dihtrkoItLAmvIrOldhXd7IfRTHslqvs i1FdLM586hl16M44hr7srLuk1XYZzCYFDSoPuICW61Tv7rldn6A7brfsM6bDPKSK9RGL clNCQhv6d3fk95eGHlKSG2+DLPlrqfwMsxUUjBA39MQOBaxXLr/VKzwLC2KuS+s3yzlv QqQXXmQ1LaMZndeJemSyB92PDD7CV1EeAN/y3/noSiNkKVId1XZn3Zo1BXK6RpT06Dzv ohhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727014375; x=1727619175; 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=moknVuz5lyC5Ycb1Ux95VyjnWgGb3KsUBQVvJ5nf//s=; b=lmmTPHHZ1TpA9VgX6uS0MhvmscaUtisVNDoPz1rU/n1mTUq0zQhhOLQgnS5eP4g0Az ff8zWXDYwxYMUpt58LAAOo7yrCB47gGuW8cw8CSpfnu8f6BAEMH0/eMCeh69tI5DvcMX Fnvhc+XQBjDeRVO65bAp7/QEGchTeahsxbPh50lUN3f5s9+xJUZnkuuKIXoPWsFYmR89 DhOUg07nyLfk/rE8HrmiQIOzIj9eghaudb6Saga5IcnvT9Qwy0ZfZGV+X/t3BR0W9Ngb jKiTMyJD2bCw5JSBpGgpC2ooR2y8kxJxSIBk/Gyt2PFMzESh6Dw1Iw7tDY9Er3Jqov+1 ykHA==
X-Forwarded-Encrypted: i=1; AJvYcCW7EMrRSSQHVvNMuVPrxpPgHjVHjBvibwDknZuUYjUmXM1UN/uJi1FdpI8KQsvaNRzb3ipsDg==@ietf.org
X-Gm-Message-State: AOJu0YzbZLMA3WdRt06CM768WJGGghAxteGq58ET+s0VK9rkb2Mx03Cn IML87C/dX5ywWOmv680FPNPzaJThV1RULd2GKwCim9nbZMoK/1/tm5Q7Votu2sOLcH1fOnLi65G a0TknK74gBz71yhC4Qdmhb9xJnEZceXoR87E=
X-Google-Smtp-Source: AGHT+IGiDmQZw0sFD34wqWkYgIlCNgGeW/VIvB5txvnZVVBVIpQClMVHFQy7zuQvpt8FoGoat4bv+oYZPN66bbp1FFM=
X-Received: by 2002:a05:690c:311:b0:6dd:de41:fee1 with SMTP id 00721157ae682-6de09863103mr94657177b3.18.1727014375408; Sun, 22 Sep 2024 07:12:55 -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> <SJ0PR02MB74392337DDF75B31B1915EC5B76D2@SJ0PR02MB7439.namprd02.prod.outlook.com>
In-Reply-To: <SJ0PR02MB74392337DDF75B31B1915EC5B76D2@SJ0PR02MB7439.namprd02.prod.outlook.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Sun, 22 Sep 2024 16:12:19 +0200
Message-ID: <CAD9ie-sE7VGPT9w0yy60hX=JOABi5BJdreR71VZHe3idfCi5_g@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Content-Type: multipart/alternative; boundary="0000000000005e4d040622b5de09"
Message-ID-Hash: BIBGCIMAP5H7ATDPCOKPEIXPRJ7PWXMG
X-Message-ID-Hash: BIBGCIMAP5H7ATDPCOKPEIXPRJ7PWXMG
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: Leading underscores in SD-JWT Claim Names (was SD-JWT architecture feedback)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/s8Oqw_Ym-rdM3gVHcfScmKupAqY>
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>

I have a few points here as well:

1) the hash algorithm should be in the header. It is not a claim. It
describes how to process the rest of the text in the token. People parse
the header to learn what to do with the rest of the string. That was a key
decision in this format.

2) underscores typically signal that something is an internal / off limits
value. The digests are a claim in the payload that are expected to be
operated on.

3) related to that, calling the digests "digests" would be more meaningful
that "_sd" -- as that is what they are

Just because there are other claims with _ does not mean they are intuitive
to an implementer in this case. Daniel did not rationalize the use of
underscore because other claims that are meta data used an underscore.

Per my other note, I'm just giving my feedback as a community member. Zero
interest in winning an argument.

On Sat, Sep 21, 2024 at 9:06 PM Michael Jones <michael_b_jones@hotmail.com>
wrote:

> SD-JWT is following an existing OAuth (and OpenID) convention by including
> an underscore prefix in the names of claims about claims.  You’ll find that
> _claim_names and _claim_sources are registered at
> https://www.iana.org/assignments/jwt/jwt.xhtml, which are both claims
> about claims, rather than claims whose values are used in the usual way.
>   These are currently the only claims with leading underscores registered.
>
>
>
> Therefore, I believe SD-JWT is on solid ground creating and registering
> the names _sd and _sd_alg as other claims about claims.
>
>
>
>                                                                 -- 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
>
>
>
> …
>
>
>
>
>
> *Claim Names*
>
> Why do the claims start with '_'? Why not just 'sd' and 'sda'? Why is
> '_sd_alg' in the payload and not in the header?
>
> While the underscore doesn't officially have any special meaning, adding
> it reduces the chance for collisions with existing claims and makes the
> SD-JWT-related claims sort nicely. All SD-related claims are in the
> payload, that's why we put _sd_alg there as well.
>
> Do you have data that shows it will reduce collisions? I have seen many
> implementations that created their own claims that start with _ to reduce
> collisions with the same rationale!
>
>
>
>  There is an IANA registry for claim names to avoid collisions.
>
>
>
> The _ reminds me of internal C variables that others were not supposed to
> use, but eventually did.
>
>
>
> _sd_alg is NOT a claim. It is a signal for which algorithm to use and
> should be in the header.
>
>
>
> I'm unclear on the sorting advantage. They would sort together if they
> started with sd as well.
>
>
>