This is great, thank you so much! On Wed, Nov 5, 2025 at 1:22 PM David Waite <[email protected]> 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 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] > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
