Issue a passport as an SD-JWT-VC in which a holder can present a subset of claims, verifiable by any third party against the operator's published did:web key without contacting our node.
Why
Today, audience-scoped access means the node filters, which places the node in the trust path of every read. Selective disclosure at the credential layer removes us from it: a recycler can prove what a manufacturer attested about a battery without either of them talking to us.
Shape
An SD-JWT-VC is a JWS over a payload where selectively-disclosable claims are replaced by salted hashes, plus a set of disclosure strings — each the base64url of [salt, claim_name, claim_value]. A presentation is the JWS plus only the disclosures the holder chooses.
Disclosure groupings derive from the sector catalog's disclosure map, never from audience names. That map already assigns each field a class and is the source of what is selectively disclosable. Hardcoding "this role sees these four fields" reintroduces the coupling the disclosure-set work removed, one layer down where it is harder to see.
Settled
Open before code
- Who holds the disclosures? If the node stores them we are back in the trust path. Preferred: the node issues and hands them over; retention becomes an operator choice, not an architectural one.
- Key binding — real security value, but requires holders to have keys, an ecosystem assumption we cannot make yet. Design for it; do not ship it first.
- Granularity — per-unit credentials are where selective disclosure is most valuable, since the catalog already marks state-of-health and expected-lifetime fields as individual-tier.
Merge gate
- A passport issues as an SD-JWT-VC; the full credential verifies against the operator's
did:web key
- A 2-of-4 holder presentation verifies: signature valid, the two revealed claims recompute to hashes present in the payload
- The two withheld claims are not recoverable from the presentation — an explicit negative test over the presentation bytes, not assumed from construction
- Tampering with a revealed claim value fails hash recomputation
- Salts are unique per claim per credential and drawn from a CSPRNG, property-tested — a reused salt across two credentials for the same field is a correlation leak and must fail
- Two issuances of the same passport produce different salts, therefore different hashes, for the same values
Scope boundary
No ZK, no range proofs, no predicate proofs. No conformance claim — only "implements draft N, read on date". This does not replace the audience-scoped read endpoint; both exist.
Issue a passport as an SD-JWT-VC in which a holder can present a subset of claims, verifiable by any third party against the operator's published
did:webkey without contacting our node.Why
Today, audience-scoped access means the node filters, which places the node in the trust path of every read. Selective disclosure at the credential layer removes us from it: a recycler can prove what a manufacturer attested about a battery without either of them talking to us.
Shape
An SD-JWT-VC is a JWS over a payload where selectively-disclosable claims are replaced by salted hashes, plus a set of disclosure strings — each the base64url of
[salt, claim_name, claim_value]. A presentation is the JWS plus only the disclosures the holder chooses.Disclosure groupings derive from the sector catalog's
disclosuremap, never from audience names. That map already assigns each field a class and is the source of what is selectively disclosable. Hardcoding "this role sees these four fields" reintroduces the coupling the disclosure-set work removed, one layer down where it is harder to see.Settled
Open before code
Merge gate
did:webkeyScope boundary
No ZK, no range proofs, no predicate proofs. No conformance claim — only "implements draft N, read on date". This does not replace the audience-scoped read endpoint; both exist.