[jose] Re: JWP Subclaim proposal question

David Waite <david@alkaline-solutions.com> Wed, 05 November 2025 18:27 UTC

Return-Path: <david@alkaline-solutions.com>
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 <jose@mail2.ietf.org>; 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 <jose@mail2.ietf.org>; 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 <jose@ietf.org>; Wed, 5 Nov 2025 10:22:54 -0800 (PST)
From: David Waite <david@alkaline-solutions.com>
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: <CDD9C795-AD7A-4F86-A7C2-028F22E6812A@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0AC577B-06C2-49E1-9CDE-7F356E031287"
Mime-Version: 1.0
Date: Wed, 05 Nov 2025 11:22:41 -0700
In-Reply-To: <CABzCy2Dpf8bCcWxQmyjup=c3oGN2RARZbaMxpvU0MM7_udRrtg@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
References: <CABzCy2Dpf8bCcWxQmyjup=c3oGN2RARZbaMxpvU0MM7_udRrtg@mail.gmail.com>
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: [jose] Re: JWP Subclaim proposal question
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/JMTcPKfBdkE27n84EF2-VH8CzYc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

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’t an obvious referencable standard for dot-flattening, but it does compare to JSON Pointer [4] which uses a path syntax (“/address/country”) . 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’t distinguish from “0” as an object property/map key and “0” 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 “/“ for pointers (and “.” 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 “1” 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’t 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-syntax/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-claim-path

> On Nov 5, 2025, at 10:18 AM, Nat Sakimura <sakimura@gmail.com> wrote:
> 
> Thanks, Mike, for presenting https://datatracker.ietf.org/meeting/124/materials/slides-124-jose-json-web-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