Skip to content

Add SD-JWT selective disclosure guidance for credential privacy #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
chongkan wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add SD-JWT selective disclosure guidance for credential privacy #40

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 43 additions & 4 deletions did-pkh-method-draft.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -235,13 +235,52 @@ where all supported dids are assumed to be capable of deactivation.

### Key Derivation Lacks Proof

Some implementations might utlize a key derivation function, e.g., when
converting from an ed25519 public key to a Curve25519 ECDH key, used in the
Some implementations might utlize a key derivation function, e.g., when

@TallTed TallTed Mar 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Some implementations might utlize a key derivation function, e.g., when
Some implementations might use a key derivation function, e.g., when

converting from an ed25519 public key to a Curve25519 ECDH key, used in the
keyAgreement verification method (in did-key, and perhaps in future CAIP-based
pkh implementations). It is expected that this is a relatively safe operation,
but implementers might consider that there exists no mathematical proof that
pkh implementations). It is expected that this is a relatively safe operation,
but implementers might consider that there exists no mathematical proof that
confirms this assumption.
Comment on lines +241 to 243

@TallTed TallTed Mar 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pkh implementations). It is expected that this is a relatively safe operation,
but implementers might consider that there exists no mathematical proof that
confirms this assumption.
pkh implementations). This operation is expected to be relatively safe,
but implementers might consider that there exists no mathematical proof that
confirms this expectation.


### Credential Privacy and Selective Disclosure

Since `did:pkh` identifiers are derived from public blockchain addresses, they
are inherently correlatable — the same address is visible on-chain and used as
the DID. This makes credential privacy particularly important.

Credentials issued to `did:pkh` holders SHOULD use
[SD-JWT](https://datatracker.ietf.org/doc/html/rfc9449) (Selective Disclosure
for JWTs) to minimize data exposure during presentation:

1. **Issuance:** The issuer creates an SD-JWT credential with per-claim salts
and hashes, bound to the `did:pkh` holder's key via Key Binding.
2. **Storage:** The holder stores the full SD-JWT off-chain (wallet, device).
No credential data is stored on-chain.
3. **Presentation:** The holder discloses only the claims required by the
verifier's presentation definition. For example, proving `age >= 18`
without revealing date of birth or name.
4. **Verification:** The verifier resolves the `did:pkh`, retrieves the
holder's public key from the DID Document, and verifies the SD-JWT
signature and Key Binding proof.

**Key Binding algorithms by network:**

| Network | Key Binding Algorithm |
|---|---|
| Ethereum, Polygon, Celo, Bitcoin, Dogecoin | `ES256K` (secp256k1) |
| Solana | `EdDSA` (Ed25519) |
| Tezos (tz1) | `EdDSA` (Ed25519) |

Key Binding prevents credential replay — a stolen SD-JWT cannot be presented
by an attacker who does not control the holder's private key.

**Correlation mitigation:** Since `did:pkh` maps 1:1 to a blockchain address
and cannot be rotated or aliased, holders concerned about cross-verifier
correlation SHOULD use the `alsoKnownAs` link to a DID method that supports
pairwise identifiers (e.g., ENS subdomains via `did:ens`, or `did:peer` for
ephemeral sessions). The `did:pkh` remains the cryptographic anchor; the
pairwise DID is what gets shared with verifiers.

## Ref Impl

|Author|name of implementation|link to pkh libraries|date registered|
Expand Down