Add draft-solana-session-passkey-00: passkey extension to Solana Session Intent

[BranchManager69]

Add passkey extension: draft-solana-session-passkey-00

This PR adds a sibling extension document under specs/methods/solana/ that fills the four required items the Solana Session Intent draft invites at its Authorized Signer section (draft-solana-session-00, §Authorized Signer):

1. Distinct signatureType value: passkey-p256-session-v1
2. Exact signed message format: 180-byte fixed layout for session-key registration, 128-byte for revocation, both with domain-separated 32-byte prefixes (OTS_SESSION_REGISTER_V1 and OTS_SESSION_REVOKE_V1)
3. Exact on-chain verification program: Solana's native Secp256r1SigVerify1111111111111111111111111 precompile (SIMD-0075), introspected via the instructions sysvar
4. Binding between delegated signer and channel PDA: the session key (Ed25519) is recorded on a vault account whose passkey is verified at registration time; the channel's authorizedSigner references the session key, the session key references the vault, the vault stores the passkey pubkey

What's in the document

• Wire format with byte-level layout tables and hex examples
• WebAuthn signing ceremony (challenge construction, clientDataJSON parsing semantics)
• SIMD-0075 introspection flow (offsets, asserts, failure modes)
• Off-chain verifier flow for vouchers and for application-level liveness (prove_passkey)
• Security considerations covering the "passkey is not a hardware wallet" critique, replay protection, session-key compromise, program upgrade authority, and origin-pinning responsibility
• A worked test vector: 180-byte serialized registration message in hex, with its SHA-256

Reference implementation

A live reference implementation is on Solana mainnet:

• Authority program: Hg3wRaydFtJhYrdvYrKECacpJYDsC9Px7yKmpncj2fhc
• Reference vault: 7FE9VUeabi3sF8wUABV7F3eyvEi1ekDbER9k5JBYrWAi
• Source: https://github.com/Dexter-DAO/dexter-vault

The spec's normative claims have been bytecode-verified against the deployed program. All three loaded ELF sections (.text, .rodata, .data.rel.ro) match the local anchor build artifact byte-for-byte:

Section	Size	SHA-256
.text	230,920	26381d21f25a272ac2964ce229bb0708db15313e0e4acfa85f20f6a4033b6197
.rodata	16,488	6d398fe8ead3cbb97c6b011b1dc9f564c4980c2a4c4d74f459d10120bee0c5db
.data.rel.ro	6,152	be7a95d2a266cda44c0d03ceac5a030f5d77039086a0b0a57f68d9becfc4ea14

A reproducibility script is included in the spec (Section 8.1) so any reviewer can verify the match with solana program dump + anchor build + a 10-line Python check.

Why now

The base draft's §Authorized Signer explicitly invites passkey extensions and specifies the four items any such extension must define. The reference implementation has been live on Solana mainnet since 2026-05, and the passkey extension hole in the spec is currently unfilled. Submitting this extension now lets the broader MPP ecosystem reference a concrete, bytecode-audited reference rather than relying on future implementations to converge on compatible wire formats independently.

Relationship to base spec

This extension is additive. Channels opened under the default Ed25519 authority continue to operate without modification. Vouchers under this extension are distinguished by signatureType == "passkey-p256-session-v1", which non-implementing verifiers correctly reject as fail-safe.

The 48-byte voucher Borsh layout from the base spec is unchanged.

Open to feedback on

• Whether the document should live under specs/methods/solana/extensions/ or as a sibling at specs/methods/solana/ (current location)
• Whether the witness-binding mechanism (currently omitted in v1, noted as a possible v2 addition informed by TIP-1053) should be folded into v1 before this lands, or kept for a future revision
• Naming: passkey-p256-session-v1 vs alternatives like webauthn-session-v1 or secp256r1-session-v1
• Whether the reference-implementation section should be normative or strictly informative

Happy to revise based on review.