> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sumvin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Attestation claims

> The attestation claims Sumvin issues in identity JWTs and how to consume them.

An **attestation claim** is a named, verifiable fact Sumvin embeds in the JWT issued for a <Tooltip headline="Stamped Mandate" tip="A signed authorisation a user grants for specific scoped actions — delivered on the wire as a PINT." cta="Glossary →" href="/glossary">Stamped Mandate</Tooltip>. The claim is signed by <Tooltip headline="SIS" tip="Sumvin Identity Service — the B2B API that exchanges signed Stamped Mandates for JWTs." cta="Glossary →" href="/glossary">SIS</Tooltip>, so any verifier can trust it without calling back to the user, the KYC provider, or any third-party attestation source.

<Snippet file="product-term-disambiguation.mdx" />

A Stamped Mandate is delivered over the API as a `PINT` (header `x-sumvin-pint-token`). Claims appear on a JWT when the Stamped Mandate requesting it carries a [scope](/identity/scopes) 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

| Source                  | Claims it feeds                                  | How it reaches the JWT                                                                                                       |
| ----------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| **KYC verification**    | `kyc_status`, `age_over_18`, identity attributes | On PINTs carrying a Sigil scope (`sr:us:pint:sigil:kyc_status`, `sr:us:pint:sigil:kyc_read`, `sr:us:pint:sigil:age_over_18`) |
| **User profile**        | Proof-of-personhood, residency metadata          | On PINTs carrying `sr:us:pint:sigil:proof_of_personhood`                                                                     |
| **Transaction history** | Account reads, spend history claims              | On 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 Stamped Mandate's scopes granted access. Partners cannot extract a claim by asking for a JWT; the user (or their agent) has to have signed a Stamped Mandate that authorised the read.

## How a verifier consumes a claim

1. Verify the JWT per the [Verify a JWT guide](/merchant/verify-jwt) — 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](/merchant/verify-pint-signature) path.

Claims are freshness-bound to the JWT's `exp`. If the claim's underlying truth changes (KYC regresses, policy is revoked), the Stamped Mandate that produced the JWT can be revoked — see [Revocation](/concepts/revocation).

## See also

* [Getting user KYC data](/identity/getting-user-kyc-data) — full KYC claim payload and the read flow
* [Scopes reference](/identity/scopes) — which scope triggers which claim
* [Verify a JWT](/merchant/verify-jwt) — JWT verification path that surfaces claims
* [JWT reference](/identity/jwt) — canonical JWT shape