Skip to main content
SIS uses a federated identity model: every Sumvin user has a unique identity (their Sumvin Resource Identifier, or SRI) regardless of which embedded wallet provider issued their wallet. Configuring your auth provider tells SIS how to validate the JWTs your users carry.

​
The Validation Flow

When your app makes a call to SIS on behalf of a user: 
1. User signs in to your app via Dynamic or Privy
2. Provider issues a JWT to the user's browser
3. Your app calls a SIS endpoint, passing the JWT in the `x-juno-jwt` header
4. SIS validates the JWT against your configured provider credentials for that environment
5. SIS resolves the user's Sumvin Resource Identifier (SRI) and returns identity data
Each step depends on your environment’s auth configuration being set up correctly. If the credentials don’t match the provider that issued the JWT, validation fails.

​
Why Credentials Are Per-Environment

SIS needs to know which provider public key to validate JWTs against. Separating credentials per environment:
  • Prevents cross-environment leakage — a development JWT can’t authenticate against your production environment
  • Lets you test provider credential rotations in staging before production
  • Gives you an audit trail per environment

​
Supported Providers

ProviderAuth Method
DynamicEnvironment ID + Public Key (JWK)
PrivyApp ID + Verification Key
Only one provider can be active per environment at a time. See Auth Provider Setup for the full configuration steps.

​
What SIS Returns

After successful JWT validation, SIS resolves and returns:
  • The user’s SRI (Sumvin Resource Identifier) — their stable identity across all providers
  • Identity data associated with the SRI: KYC status, wallet addresses, and verification claims
See the SIS API Reference for the full response schema.

​
Verification Tiers

Third-party integrators operate at one of two verification tiers depending on the scopes they access. Standard integrations receive a JWT with identity attestation. Enhanced integrations (those processing spend authorisation) additionally receive the cryptographic signature (user- or agent-signed) for independent verification. See the Verification Tiers guide for the complete reference on integration requirements per tier.