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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
