Return-Path: X-Original-To: jose@mail2.ietf.org Delivered-To: jose@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id CB466841AAC3 for ; Wed, 5 Nov 2025 20:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa91eoiHVXev for ; Wed, 5 Nov 2025 20:59:14 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 mail2.ietf.org (Postfix) with ESMTPS id 1A092841AABC for ; Wed, 5 Nov 2025 20:59:14 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-2957850c63bso6716085ad.0 for ; Wed, 05 Nov 2025 20:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762405147; x=1763009947; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ziCSdSKVcP15E/7Li2OXjYt+mb3dzPHZYoGHdp1hKEk=; b=VnIzD+CnlzwxDlH1VxRnOHqDFtJZWVzJOeQV+NPtJubl6hEUcwxoV47ALRvxcfBAul nj9teCADAyic4/s+XNNpE2WRS54MPJf4DboeiknxO3FLioQFMy3dH+oVfqcmLz5UYwuc IJn4TJbJ7ggmY0raut1JJQE1F5uj88sVZdyLGPpAAwyNT68Oh8cRlQWWwW3Pvc0bv7F5 88fFMbH5UBd5SjYG9vYyLwcGeUUav7v5aSbGBuE2CNYNA34lo++o9eQMkUx5V8yFobTf 2xda4w4jiKIXK0c3v7NaQyVcCKiwKnzwWxhfaE8/TXrXpTh5JrfAkcfFk73QGMhHrt7l Gd9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762405147; x=1763009947; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ziCSdSKVcP15E/7Li2OXjYt+mb3dzPHZYoGHdp1hKEk=; b=J2nUk2MeCZZTRA4qFPxOn42ZTRPjF6ZM0W3du+FRPeV3C6WbkzTmazKxj6KPI3LSh9 SRmJmVeJEzcQnUkfE+QoIM9Q/YCDmh3ucJb/atvBfBDQmzHtQopmfwgDAQzwT75wlMx9 oRHeozffgrrDhytBrr22jqQvqauzNoffaxk8A9jpuUAerZDXNKH6eT3umHQeb7nu7pwv pd1WkU9Il5YyOsB7+LMe/rPDbtmvHrsYjvcSiKoGnFLVfoAm8F2XrCDbWu2Eyr4iSYg0 x0DdmuXJjC/9FdT6+YBKp1Zve0qdAJzd7PG2adhhXaqT1vci6whPIzT8Ds4sXzBX3Usv d52g== X-Gm-Message-State: AOJu0YzPg30BeGZnYWnc04bgKcSL/NJAN9IgV3JVAe5FdeKTdpL4fSsY 4RCCsGJejWhsPklMgNxaTnqfyHVNdeQ38zlbx6VjX0vqVeB85QZsjVGThO6yZfH1gsjsgdTjqzR HuWXGZOVUb4WSY68utqjgju3O/w6Mo04= X-Gm-Gg: ASbGncvMzSNG4kkrWearLv4g33px75p8Ztp8pd+mp3eJppoE+jUiUXRpqVnefWEAce0 rzPjmoMYCPf8o6e/49iXesiMkct8vSjUpn1X1wXv4FlabCOkpoRwTtem5nCWh5O9vLYGVaqKBvr 8zhikA9iZ4OBu9Wxnbab5EQ6XJHvpSFhTL29C9jOFK7Rv6p+XduhUUQwwkPil47ImnhUJTZ5APi 9cJmPfR8ueuyjxCf1hls87722/9eVr9m2xLYKZzd1pXBIgYXF5n+R17Zk/TaXDcGb7dkU3A3KFj 5N1cXfKD+tCi9xy4 X-Google-Smtp-Source: AGHT+IEwLeY/ZFEa046eP0XZEAzx/HLLomXS18WU0e6M0IPFGb8FTJEpy2FL+XZcEVdR19BVcd2cdTjX/Kk4fWBwYc4= X-Received: by 2002:a17:903:1b0d:b0:266:57f7:25f5 with SMTP id d9443c01a7336-2965086027amr23675285ad.7.1762405146788; Wed, 05 Nov 2025 20:59:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Wed, 5 Nov 2025 23:58:55 -0500 X-Gm-Features: AWmQ_bkJgRMcjeq4FuA7-IEp8kcTSBYUD_PkFz28Glsx0HLUc2yc6yJNlztil4E Message-ID: To: David Waite Content-Type: multipart/alternative; boundary="000000000000b989780642e5ec03" Message-ID-Hash: NNWYE6LBCTCG6L3HKJLFMWVPGHKWEVOE X-Message-ID-Hash: NNWYE6LBCTCG6L3HKJLFMWVPGHKWEVOE X-MailFrom: sakimura@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: jose@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_JWP_Subclaim_proposal_question?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b989780642e5ec03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is great, thank you so much! On Wed, Nov 5, 2025 at 1:22=E2=80=AFPM David Waite wrote: > Hello Nat! > > Before discussion kicks off, I wanted to make sure to provide the list > additional information. > > I want to mention there is a PR [1] describing the approach briefly > mentioned in the presentation, as well as the CI rendering of the changed > document [2]. > > The slide deck is also available [3]. The chart in the PPTX has a few > options I researched and presenter notes, but we didn't really have time = to > present the information during the meeting. (The PDF seems to strip the > check marks as they are in the emoji unicode range, something I'll keep i= n > mind for the future.) > > There isn=E2=80=99t an obvious referencable standard for dot-flattening, = but it > does compare to JSON Pointer [4] which uses a path syntax > (=E2=80=9C/address/country=E2=80=9D) . The feature-set is close to what w= e want, but there > were a few negatives per our criteria: > > 1. It would require a different approach for CBOR, which has broader > fidelity including allowing any CBOR to be used as a map key. > > 2. If we want to allow for document reconstruction, we can=E2=80=99t dist= inguish > from =E2=80=9C0=E2=80=9D as an object property/map key and =E2=80=9C0=E2= =80=9D as an array index, since > both are expressed as string data. We would need to understand the > semantics of a claim to distinguish these cases, which complicates > implementation. > > 3. There are additional parsing and escaping rules, since =E2=80=9C/=E2= =80=9C for pointers > (and =E2=80=9C.=E2=80=9D for dot-flattened) are characters allowed in a J= SON object key. > > CBOR Pointer [5], OpenID4VP [6] and SD-JWT-based Verifiable Credentials > [7] use an array syntax, which is less terse but skips the need for parsi= ng > and escaping. Since it can distinguish 1 as an array index and =E2=80=9C1= =E2=80=9D as a map > key, it also allows for a subset JSON document to be reconstructed based = on > released claims and subclaims. (CBOR reconstruction is more complex due t= o > the higher fidelity) > > It also is worth noting that while we describe how to embed the mapping o= f > payloads to claims and subclaims as an issuer header, we would like to pu= sh > applications to instead have consistent mappings that could leverage issu= er > metadata (similar to that defined by the SD-JWT based Verifiable > Credentials draft). In that case, we wouldn=E2=80=99t have a claims list = in the > header, and would have less benefit from the additional terseness of a > flattened string syntax. > > -DW > > [1]: https://github.com/ietf-wg-jose/json-web-proof/pull/187 > > [2]: > https://ietf-wg-jose.github.io/json-web-proof/change-jpt-to-array-query-s= yntax/draft-ietf-jose-json-proof-token.html#name-claims-header-parameter > > [3]: https://datatracker.ietf.org/doc/slides-124-jose-json-web-proofs/ > > [4]: https://datatracker.ietf.org/doc/html/rfc6901 > > [5]: https://www.ietf.org/archive/id/draft-mahy-cbor-pointer-00.html > > [6]: > https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-= claims-path-pointer > > [7]: > https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-12.html#name-c= laim-path > > On Nov 5, 2025, at 10:18=E2=80=AFAM, Nat Sakimura wr= ote: > > Thanks, Mike, for presenting > https://datatracker.ietf.org/meeting/124/materials/slides-124-jose-json-w= eb-proofs-00 > today. > > I have one question about the Subclaim proposal. > In the slide, you proposed array flattening, e.g. ["address","country"] > and not dot-flattening, e.g. "address.country", which is a popular choice > as well. Is there a reason for picking array flattening? Just wanted to > know. > > Thanks, > > -- > Nat Sakimura > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-leave@ietf.org > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000b989780642e5ec03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is great, thank you so much!=C2=A0

On Wed, Nov 5, 2025 at 1:22=E2=80=AFPM David Waite <david@alkaline-solutions.com> wrote:<= br>
H= ello Nat!

Before discussion kicks off, I wan= ted to make sure to provide the list additional information.

=
I want to mention there is a PR [1] describing the approach brie= fly mentioned in the presentation, as well as the CI rendering of the chang= ed document [2].

The slide deck is also available = [3]. The chart in the PPTX has a few options I researched and presenter not= es, but we didn't really have time to present the information during th= e meeting. (The PDF seems to strip the check marks as they are in the emoji= unicode range, something I'll keep in mind for the future.)
=

There isn=E2=80=99t an obvious referencable standard fo= r dot-flattening, but it does compare to JSON Pointer [4] which uses a path= syntax (=E2=80=9C/address/country=E2=80=9D) . The feature-set is close to = what we want, but there were a few negatives per our criteria:
1. It would require a different approach for CBOR, which has b= roader fidelity including allowing any CBOR to be used as a map key.
<= div>
2. If we want to allow for document reconstruction, we c= an=E2=80=99t distinguish from =E2=80=9C0=E2=80=9D as an object property/map= key and =E2=80=9C0=E2=80=9D as an array index, since both are expressed as= string data. We would need to understand the semantics of a claim to disti= nguish these cases, which complicates implementation.

3. There are additional parsing and escaping rules, since =E2=80= =9C/=E2=80=9C for pointers (and =E2=80=9C.=E2=80=9D for dot-flattened) are = characters allowed in a JSON object key.

CBOR Poin= ter [5], OpenID4VP [6] and SD-JWT-based Verifiable Credentials [7] use an a= rray syntax, which is less terse but skips the need for parsing and escapin= g. Since it can distinguish 1 as an array index and =E2=80=9C1=E2=80=9D as = a map key, it also allows for a subset JSON document to be reconstructed ba= sed on released claims and subclaims. (CBOR reconstruction is more complex = due to the higher fidelity)

It also is worth notin= g that while we describe how to embed the mapping of payloads to claims and= subclaims as an issuer header, we would like to push applications to inste= ad have consistent mappings that could leverage issuer metadata (similar to= that defined by the SD-JWT based Verifiable Credentials draft). In that ca= se, we wouldn=E2=80=99t have a claims list in the header, and would have le= ss benefit from the additional terseness of a flattened string syntax.

-DW


=






On Nov 5, 2025, at 10:18=E2=80=AFAM, Nat Sakim= ura <sakimura@gm= ail.com> wrote:


I have one question about the Subclaim prop= osal.=C2=A0
In the slide, you proposed array flattening, e.g. [&q= uot;address","country"] and not dot-flattening, e.g. "a= ddress.country", which is a popular choice as well. Is there a reason = for picking array flattening? Just wanted to know.=C2=A0

Thanks,=C2=A0

--
Nat Sakimura<= br>
_______________________________________________
jose mailing list -- jose@ietf.org
To uns= ubscribe send an email to jose-leave@ietf.org



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.or= g/
@_nat_en
--000000000000b989780642e5ec03--