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 F03F883C524A for ; Wed, 5 Nov 2025 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 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, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=alkaline-solutions.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 zqTbBIdjKHhb for ; Wed, 5 Nov 2025 10:27:40 -0800 (PST) Received: from caesium6.alkaline.solutions (unknown [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 mail2.ietf.org (Postfix) with ESMTPS id 6CF1783C4B51 for ; Wed, 5 Nov 2025 10:22:54 -0800 (PST) From: David Waite DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1762366973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=a71SFmAyJAgoL4dTIhJnTWcildR9a4Lqm+yOEHgz0vc=; b=ssCsWAu1GA2ZGnU/D5Y3myOfgbtNSHFxiYCdhg9efkF+GVmlqNG4asYsEom1qbs+FCBeQN g0KsYf/ysp3zIH816EYbW+wLL0pa1JB0CYfAEuvKDCEiMxqlBud3lx0aXBbchSD6IsjXc1 JHEf1s8xnbqsZlXm9r75GDt7rUNIIXZ+ozb1jPcnOkaUyIosGZR06NTx2Mt1D20CRoS/cx Tp1Ex/Ff7k9VaLf/gRIlJLcysUV5jdXi4X/G+cxj+R3R+mNBBcV7wifDr2vglEpp0DfinN 7u1ClIN3edyuBlXgn044OedoCWNNgpMeRPTmYNfgmMUxVzXsJ3drwECcuEkOgw== Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F0AC577B-06C2-49E1-9CDE-7F356E031287" Mime-Version: 1.0 Date: Wed, 5 Nov 2025 11:22:41 -0700 In-Reply-To: To: Nat Sakimura References: X-Spamd-Bar: -- Message-ID-Hash: TVWEI3I237EEEM6HUMBGTZHEFSD2RXBJ X-Message-ID-Hash: TVWEI3I237EEEM6HUMBGTZHEFSD2RXBJ X-MailFrom: david@alkaline-solutions.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: --Apple-Mail=_F0AC577B-06C2-49E1-9CDE-7F356E031287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 in 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 = we 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 = 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 = 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 JSON 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 = parsing 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 to the higher fidelity) It also is worth noting 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 instead have consistent mappings that could = leverage issuer 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-sy= ntax/draft-ietf-jose-json-proof-token.html#name-claims-header-parameter [3]: https://datatracker.ietf.org/doc/slides-124-jose-json-web-proofs/=20= [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-c= laims-path-pointer [7]: = https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-12.html#name-cl= aim-path > On Nov 5, 2025, at 10:18=E2=80=AFAM, Nat Sakimura = wrote: >=20 > Thanks, Mike, for presenting = https://datatracker.ietf.org/meeting/124/materials/slides-124-jose-json-we= b-proofs-00 today.=20 >=20 > I have one question about the Subclaim proposal.=20 > 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.=20 >=20 > Thanks,=20 >=20 > -- > Nat Sakimura > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-leave@ietf.org --Apple-Mail=_F0AC577B-06C2-49E1-9CDE-7F356E031287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 in 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 we 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 = 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 = 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 JSON = 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 parsing 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 = to the higher fidelity)

It also is worth noting = 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 = instead have consistent mappings that could leverage issuer 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






[7]: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-= vc-12.html#name-claim-path

On Nov 5, 2025, at 10:18=E2=80=AFAM, Nat Sakimura = <sakimura@gmail.com> wrote:


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

= --Apple-Mail=_F0AC577B-06C2-49E1-9CDE-7F356E031287--