Skip to main content
Signing Services is the boundary that holds Sumvin’s signing keys and produces signatures and JWTs on behalf of users and their agents.

​
Why this exists

Identity-bearing signatures need to come from keys that nobody — not Sumvin staff, not partners, not the user — can extract. Signing Services is the internal surface that holds those keys in HSM-backed Google Cloud KMS, exposes a narrow signing API, and never returns the private material. Every PINT agent signature and every SIS-issued JWT is produced here. You do not call Signing Services directly as a partner. You touch it transitively — when you exchange a signed PINT for a JWT, when an agent signs a PINT for a user, or when a verifier resolves a kid against the JWKS endpoint. This page describes what is happening on the other side of those calls so the rest of the docs make sense.

​
The two key families

Signing Services holds two families of signing keys. They do different jobs and rotate on different cadences.
FamilyCurve / algorithmPurposeWhere the public half lives
Agent signing keysP-256 (EC_SIGN_P256_SHA256)One per user. Signs PINTs when an agent acts on a user’s behalf. Verified on-chain through the user’s Safe via EIP-1271.The user’s Safe contract owns the corresponding signer proxy. See Agent signers.
Issuer keysES256 (EC_SIGN_P256_SHA256)Signs every PINT JWT issued by SIS at token exchange time.Published at the endpoint; each JWT carries a kid resolving to the signing key version.
Both families live in the same KMS key ring but serve disjoint purposes. Agent keys produce signatures that resolve through a Safe. Issuer keys produce signatures that resolve through JWKS.

​
How partners reach this surface

The partner-visible boundary is always /v0/sis/token/pint and /v0/sis/.well-known/jwks.json. Signing Services is hidden behind those.

​
Surface map

The components that make up Signing Services in production:
  • Agent key custody. Per-user P-256 key, named agent-signer-{external_id}, lives in the sumvin-agent-keys KMS key ring with HSM protection level.
  • Issuer key custody. ES256 JWT signing key in the same KMS key ring. The kid on each issued JWT is the full KMS crypto-key-version resource path, so verifiers do not need to know the underlying key name.
  • Signing service client. Route-scoped HTTP client used during PINT exchange to ask the agent transaction worker for an EIP-712 signature. Returns the signature or a structured error; never exposes private key material.
  • Durable signing workers. Workflow-only calls used during agent signer setup and Safe creation. These deploy the signer proxy contract and the user’s Safe; they are not called from request paths.

​
Key rotation

Agent signing keys are bound 1:1 to a user. They are not rotated as a routine operation today — rotation requires re-deploying the signer proxy contract and re-binding to the Safe. Issuer keys rotate independently of any user. The kid claim on every JWT lets verifiers resolve the right public key from JWKS regardless of when rotation happens, so verifiers must always honour kid rather than caching a single key.

​
Failure model

Signing Services calls — both the route-scoped signing client and the durable workflow calls — return structured error responses rather than raising. A WORKER_ERROR with can_retry=true is safe to retry; WORKER_INVALID_RESPONSE is not. PINT exchange propagates failures as RFC 7807 errors with the appropriate PINT-* error code so partners see a normal 4xx/5xx rather than a leaked internal failure.

​
See also