Add cross-chain verification examples

did-pkh-method-draft.md

@@ -242,6 +242,85 @@ 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.
 
+## Cross-Chain Verification Examples
+
+This section illustrates how `did:pkh` serves as a cryptographic bridge for
+cross-chain credential verification. Since `did:pkh` wraps raw blockchain
+addresses, it provides the key-proof layer that links richer DID methods across
+chains.
+
+### Example 1: Verifying a did:sns credential via did:pkh
+
+A credential is issued to `did:sns:alice.sol` on Solana. A verifier who only
+supports `did:pkh` can still verify it:
+
+```
+Credential:
+  issuer: did:web:university.edu
+  credentialSubject.id: did:sns:alice.sol
+  proof: EdDSA signature by alice's Ed25519 key
+
+Verification:
+  1. Verifier receives VP signed by did:sns:alice.sol
+  2. Verifier cannot resolve did:sns (no Solana resolver)
+  3. Holder provides alsoKnownAs hint:
+     did:pkh:solana:4sGjMW1sUnHzSxGspuhpqLDx6wiyjNtZ:CKg5d12Jhpej1JqtmxLJgaFqqeYjxgPqToJ4LBdvG9Ev
+  4. Verifier resolves did:pkh (generative — no network call needed)
+  5. Verifier extracts Ed25519 public key from did:pkh DID Document
+  6. Same key as did:sns — signature verifies ✓
+```
+
+The `did:pkh` acts as a universal key-proof: the verifier trusts that the
+Solana address `CKg5d12J...` controls the Ed25519 key, without needing a
+Solana-specific resolver.
+
+### Example 2: Cross-chain identity fan-out
+
+A user controls accounts on multiple chains and links them via `alsoKnownAs`:
+
+```
+did:pkh:eip155:1:0xABC...          (Ethereum key proof)
+  └─ alsoKnownAs: did:ens:alice.eth  (full-lifecycle, services, key rotation)
+
+did:pkh:solana:...:CKg5d12J...     (Solana key proof)
+  └─ alsoKnownAs: did:sns:alice.sol  (full-lifecycle, SD-JWT, DIDComm)
+
+did:ens:alice.eth
+  └─ alsoKnownAs: did:sns:alice.sol  (cross-chain bridge)
+```
+
+A verifier receiving a credential from any of these DIDs can traverse the
+`alsoKnownAs` graph to establish that they all belong to the same subject.
+The `did:pkh` entries serve as chain-specific key proofs, while `did:ens`
+and `did:sns` provide the service endpoints, key rotation, and selective
+disclosure capabilities.
+
+### Example 3: did:pkh as SIWE/SIWX authentication → credential presentation
+
+```
+1. User authenticates via Sign-In With Ethereum (SIWE)
+   → produces CACAO object bound to did:pkh:eip155:1:0xABC...
+
+2. Platform resolves did:pkh, follows alsoKnownAs → did:ens:alice.eth
+
+3. Platform discovers CredentialExchange service endpoint in did:ens DID Document
+
+4. Platform requests VP via the service endpoint
+
+5. User presents SD-JWT credential (issued to did:sns:alice.sol)
+   via pairwise did:ens subdomain
+
+6. Platform verifies:
+   - SIWE session is valid (did:pkh key proof)
+   - did:pkh → did:ens link is bidirectional ✓
+   - did:ens → did:sns link is bidirectional ✓
+   - SD-JWT signature and Key Binding valid ✓
+```
+
+This flow starts from a standard Web3 wallet connection (SIWE) and arrives
+at a verified selective-disclosure credential presentation — bridging three
+DID methods without the user installing anything beyond a standard wallet.
+
 ## Ref Impl
 
 |Author|name of implementation|link to pkh libraries|date registered|