Delegate SD-JWT#

Gareth Oliver (Google).

• Why: Delegation of verifiable credentials with selective disclosure — the exact mechanism agentic payments need (user authorizes an agent to spend, merchant/bank sees only the delegated slice) and that plain SD-JWTs can't express.
• What: An extension letting a Holder delegate to a Delegate Holder by making the Key Binding JWT itself an SD-JWT with its own disclosures and its own key binding: <issuer-jwt>~<disclosures>~~<kb-sd-jwt>~<disclosures>~<kb-jwt>. The whole design fits in that one line — the delegation is a holder-signed SD-JWT whose payload hashes and binds the issuer's original (sd_hash, cnf for the delegate's key).
• How: Standard SD-JWT disclosure machinery at each layer; the verifier sees the issuer credential, the holder's delegation statement with narrowed/selective claims, and the delegate's proof of possession.
• Where applicable: Agentic systems and digital-credential delegation (power-of-attorney and vehicle-registration examples given). Individual draft; open questions include a common delegation policy language (aud, exp-style) and where revocation status lists are hosted.