Skip to main content
An attestation claim is a named, verifiable fact Sumvin embeds in a JWT. The claim is signed by , so any verifier can trust it without calling back to the user, the KYC provider, or any third-party attestation source. Claims appear on a JWT when the PINT requesting it carries a scope that authorises the read. The JWT carries the claim’s current value at the moment of issuance — a verifier reads it directly from the decoded payload.

​
Where claims come from

SourceClaims it feedsHow it reaches the JWT
KYC verification (SumSub)kyc_status, age_over_18, identity attributesOn PINTs carrying sr:us:pint:identity:* scopes
User profileProof-of-personhood, residency metadataOn PINTs carrying the corresponding identity scope
Transaction historyAccount reads, spend history claimsOn PINTs carrying sr:us:pint:accounts:read or sr:us:pint:transactions:read
Every claim is scoped — a verifier only sees claims for which the PINT’s scopes granted access. Partners cannot extract a claim by asking for a JWT; the user (or their agent) has to have signed a PINT that authorised the read.

​
How a verifier consumes a claim

  1. Verify the JWT per the Verify a JWT guide — signature, audience, expiry.
  2. Read the claim from the decoded payload.
  3. Do not re-verify upstream — the SIS signature over the JWT already attests the claim’s truth at issuance.
  4. For Enhanced-tier scopes, pair the claim read with the PINT signature verification path.
Claims are freshness-bound to the JWT’s exp. If the claim’s underlying truth changes (KYC regresses, policy is revoked), the PINT that produced the JWT can be revoked — see Revocation.

​
See also