Signing keys
Sumvin holds two families of signing keys. They do different jobs and rotate on different cadences.The two families
Agent signing keys
Each user has a P-256 agent key. When an agent signs a PINT for the user (as opposed to the user signing directly with a passkey), Sumvin produces the signature with that key on the user’s behalf. The private key is never exposed. Agent keys attach to the user’s Safe as an owner, so any signature the key produces verifies on-chain through the Safe’s EIP-1271 path. They are not the only key that can do this. A CLI mandate key — an externally owned account the Sumvin CLI generates and keeps on the developer’s own machine — is registered as an owner in the same way, so mandates the developer signs locally verify as the user too. It is not one of the families above: Sumvin never holds it, never rotates it, and cannot sign with it. See Agent signers and other Safe owners.Issuer keys
SIS holds a rotating set of ES256 keys and publishes their public halves at the JWKS endpoint. Every JWT SIS issues carries thekid of the key that signed it, so verifiers can resolve the correct public key from JWKS regardless of rotation.
Issuer-key rotation is the reason verifiers must always honour kid rather than caching a single public key — rotating without honouring kid breaks verification the moment the old key leaves the JWKS set.
Where to get the public halves
- Agent signer public keys — exposed through the agent signer APIs; not typically consumed by verifiers directly
- SIS issuer keys — published at
/v0/sis/.well-known/jwks.json(see JWKS)
See also
- Agent signers — per-user P-256 key provisioning, and how it differs from a CLI mandate key
- Signing a PINT — where these keys produce signatures
- JWKS — issuer key publication