Skip to main content
Identity-anchored login is a pattern where your app signs a user in against their Sumvin identity — inheriting their KYC-verified state and any attestation claims (age, proof of personhood) rather than re-verifying in your own silo.
A dedicated “Login with Sumvin” product surface is not covered in this release. The building blocks below — s, JWT verification, scopes, and attestation claims — are available today and can be composed into an identity-anchored login flow against the SIS API.

​
What the flow looks like

  1. Your app prompts the user to sign a carrying an identity scope — for example sr:us:pint:identity:proof_of_personhood or a KYC attestation scope.
  2. Your app exchanges the signed PINT with SIS for a JWT.
  3. The JWT travels to your login endpoint as x-sumvin-pint-token.
  4. Your backend verifies the JWT against the SIS JWKS, reads the sub claim (the user’s SRI), and inherits the verified attestations from the token body.
  5. You associate the Sumvin SRI with your local account record and issue your own session token.

​
Which primitives back it

  • SRIs are the durable, URI-style identifier for a Sumvin user (for example sr:us:person:safe:0x...). See the SRI format.
  • JWT verification is the same primitive as for checkout — verify against SIS JWKS, check aud and exp. See Verify a JWT.
  • Attestation claims carry verified facts — age, KYC status, proof of personhood — inside the JWT body. See attestation claims.
  • Identity scopes describe which verified facts the user is consenting to share. See the scopes reference.

​
Where to start

Start with the identity overview for how PINTs and JWTs work end-to-end, then the SRI format for the identifier you’ll bind to your local user record. When you’re ready to accept incoming credentials, verify a JWT covers the validation path, and the scopes reference helps you pick the right identity scope. Login-with-Sumvin is not yet a first-class product — but every primitive you need to build it against is.