@verana-labs/vs-agent-plugin-openid4vc 1.12.0-oidc4vc.7 → 2.0.0-dev.66

package/README.md

@@ -1,194 +1,164 @@
-# OpenID4VC plugin
+# OpenID4VC
 
-`@verana-labs/vs-agent-plugin-openid4vc` adds an optional OpenID4VCI issuer and OpenID4VP verifier to VS Agent.
+`@verana-labs/vs-agent-plugin-openid4vc` gives VS Agent an OpenID4VCI issuer and an OpenID4VP
+verifier for `dc+sd-jwt` credentials. It ships in every `vs-agent` image and turns on when the
+operator sets `OID4VC_CONFIG_FILE_LOCATION`. Nothing else enables it.
 
-The implemented foundation is deliberately narrow:
+What it does:
 
-- pre-authorized OpenID4VCI issuance of `dc+sd-jwt` credentials;
-- DCQL OpenID4VP requests using `direct_post.jwt` and the `x509_hash` client identifier scheme;
-- internal admin routes for creating offers and verification requests and reading their state;
-- public wallet protocol and metadata routes only;
-- certificate, DID-key, and Verana authorization checks before a presentation is accepted.
+- pre-authorized OpenID4VCI issuance of `dc+sd-jwt` credentials, valid until they expire: the
+  agent hosts no status list yet, so a credential carries no `status` claim and the `ttlSeconds`
+  of its offer is its only bound;
+- OpenID4VP requests in DCQL (`direct_post.jwt`, `x509_hash` or DID client identifier) or, for a
+  wallet that predates DCQL, Presentation Exchange (`direct_post`);
+- the `/v2/openid4vc` Administration API scope: create an offer or a request, then list, read
+  and delete.
 
-This is implementation groundwork, not EUDI certification or a claim of complete HAIP support. W3C VCDM credentials, ISO mdoc, status lists, authorization-code issuance, and production PKI onboarding are outside this foundation. See [OpenID4VC follow-up scope](../../docs/openid4vc-w3c-follow-up.md).
+Out of scope, and not implied: W3C VCDM credentials, ISO mdoc, authorization-code issuance,
+wallet-attestation trust-list distribution, production PKI onboarding, formal conformance.
 
-## Configure VS Agent
+## Not wired up yet
 
-Use the `vs-agent-openid4vc` image target. It enables `messaging,chat,openid4vc` and requires `OID4VC_CONFIG_FILE`:
+The configuration file the spec defines carries no credential type and no trust setting, and the
+agent derives none of them yet. So `createCredentialOffer` and `createPresentationRequest` answer
+`404 UNKNOWN_ID` for every `jsonSchemaCredentialId`, `createCredentialOffer` answers it for every
+`statusListId`, and reading a verified presentation answers the `RESOLVER_UNAVAILABLE` verdict.
+Four issues carry the rest:
 
-The commands below explicitly select the Colima Docker context. Omit `--context colima` when the active Docker context already points to the intended engine.
+- [#710](https://github.com/verana-labs/vs-agent/issues/710): SD-JWT VC Type Metadata, served at
+  the spec path `/vt/vct/{credentialSchemaId}`;
+- [#711](https://github.com/verana-labs/vs-agent/issues/711): credential types read from the VPR,
+  one per active issuer participant;
+- [#712](https://github.com/verana-labs/vs-agent/issues/712): the verifier trust decision on the
+  eight steps the spec now defines, with no `trust` block anywhere;
+- [#713](https://github.com/verana-labs/vs-agent/issues/713): status lists.
 
-```bash
-docker --context colima build \
-  --target vs-agent-openid4vc \
-  -t vs-agent-openid4vc:dev \
-  -f apps/vs-agent/Dockerfile .
+## Enable it
 
-docker --context colima run --rm \
+```bash
+docker run --rm \
   --env-file ./env-vars \
-  -e OID4VC_CONFIG_FILE=/run/config/openid4vc.json \
+  -e OID4VC_CONFIG_FILE_LOCATION=/run/config/openid4vc.json \
   -v "$PWD/openid4vc.json:/run/config/openid4vc.json:ro" \
-  -p 3000:3000 \
-  -p 3001:3001 \
-  vs-agent-openid4vc:dev
+  -p 3000:3000 -p 3001:3001 \
+  veranalabs/vs-agent
 ```
 
-Run both commands from the monorepo root. `env-vars` must set an HTTPS `PUBLIC_API_BASE_URL`, an `AGENT_PUBLIC_DID`, and the normal VS Agent wallet and deployment settings. The JSON file must not contain `publicApiBaseUrl`; VS Agent injects the trusted value from `PUBLIC_API_BASE_URL`. An HTTPS base path is supported and is used verbatim when composing protocol URLs. URLs containing a username or password are rejected.
+`env-vars` carries the normal VS Agent settings, with an `https://` `PUBLIC_API_BASE_URL`. The
+location can also be an `https://` URL, which the agent fetches once at startup without following
+a redirect. With Helm, put the JSON in `openid4vc.config`.
 
-### Development configuration
+## Configuration file
 
-This complete `openid4vc.json` shape passes the current configuration validator. The all-zero fingerprint is intentionally redacted and will trust no real peer. Replace it with the exact lowercase SHA-256 fingerprint of the self-signed issuer leaf before testing presentation:
+The agent reads and validates the file at startup, and refuses to start when it cannot read the
+location or validation fails. Keys are camelCase. Full reference: [[VSA-VTI-CFG-ENV-OID]](https://github.com/verana-labs/verana-spec/blob/main/v4/vs-agent/spec.md#vsa-vti-cfg-env-oid-openid4vc).
 
-```json
-{
-  "issuer": {
-    "id": "development-issuer",
-    "displayName": "Development Issuer",
-    "signing": {
-      "development": {
-        "enabled": true,
-        "commonName": "Local OpenID4VC Issuer"
-      }
-    }
-  },
-  "verifier": {
-    "id": "development-verifier",
-    "displayName": "Development Verifier",
-    "signing": {
-      "development": {
-        "enabled": true,
-        "commonName": "Local OpenID4VC Verifier"
-      }
-    }
-  },
-  "trust": {
-    "resolverUrl": "https://resolver.example/v1/trust",
-    "timeoutMs": 5000,
-    "allowedDidWebHosts": ["issuer.example"],
-    "credentialIssuerCertificates": [],
-    "developmentCertificateFingerprints": [
-      "SHA256:0000000000000000000000000000000000000000000000000000000000000000"
-    ]
-  },
-  "credentialConfigurations": [
-    {
-      "id": "employee",
-      "format": "dc+sd-jwt",
-      "vct": "https://agent.example/oid4vc/vct/employee",
-      "name": "Employee credential",
-      "description": "Development employee credential",
-      "vtjscId": "https://trust.example/vtjsc/employee",
-      "claims": ["given_name", "family_name", "role"],
-      "disclosureFrame": ["given_name", "family_name", "role"],
-      "ttlSeconds": 3600
-    }
-  ],
-  "verifierPolicies": [
-    {
-      "id": "employee-check",
-      "credentialConfigurationId": "employee",
-      "requestedClaims": ["given_name", "family_name", "role"]
-    }
-  ]
-}
-```
+Every key is OPTIONAL and `{}` is a valid file. The agent runs both capabilities whenever
+`OID4VC_CONFIG_FILE_LOCATION` is set; the file only carries what the agent cannot derive by
+itself.
+
+| Key | Requirement |
+| --- | --- |
+| `issuer` | OPTIONAL. Holds `signing`, `walletAttestationCertificates` and `keyAttestationCertificates`, each OPTIONAL. |
+| `issuer.walletAttestationCertificates` | X.509 roots of the accepted wallet providers. When non-empty, the agent requires a wallet attestation. |
+| `issuer.keyAttestationCertificates` | Roots for OpenID4VCI key attestations. When non-empty, the issuer metadata requires a key attestation on every proof. Absent, the `attestation` proof type is neither advertised nor accepted. |
+| `verifier` | OPTIONAL. Holds an OPTIONAL `signing`. |
 
-Development signing generates and persists a self-signed P-256 certificate for each role, with a DNS SAN derived from `PUBLIC_API_BASE_URL` and a DID URI SAN derived from `AGENT_PUBLIC_DID`. Before completing startup, the plugin publishes only those development public keys to the agent-owned DID through Credo's DID update API. Issuer keys use `assertionMethod`, verifier keys use `authentication`, and deterministic role-specific method IDs make restarts idempotent. When both roles share one DID, the plugin publishes them sequentially so neither relationship is lost.
+The identifier segment of each capability is fixed: `issuer` and `verifier`, so the public paths
+read `/oid4vci/issuer/...` and `/oid4vp/verifier/...`. The file declares neither, and the agent
+refuses to start on an `issuer.id` or a `verifier.id`, as it does on any other unknown key.
 
-The certificate still requires both bindings:
+The display name and the logo the agent publishes come from the ECS Service credential it holds
+about its own DID; no key of the file overrides them.
 
-- its exact fingerprint must be configured by every verifier that accepts it;
-- the auto-published public key must remain present in the DID document under `assertionMethod` for issuance and `authentication` for verifier request signing.
+### Signing modes
 
-A pin does not replace DID key binding or Verana authorization. Development signing is unsuitable for production and is not a HAIP deployment mode.
+**Development signing** (`signing` absent): the agent generates and persists a self-signed P-256
+certificate for the capability, with a common name and a DNS SAN derived from
+`PUBLIC_API_BASE_URL` and a DID URI SAN with the agent DID, and publishes the public key in its
+DID Document before it completes startup (`assertionMethod` for the issuer, `authentication` for
+the verifier). A peer verifier still has to pin the fingerprint that
+`GET /v2/openid4vc/signing-certificates` returns. Unsuitable for production.
 
-### Production signing and trust
+**Configured signing** (`signing.configured`): `certificateChain` (a non-self-signed leaf first,
+then the intermediates and the root) and the `privateJwk` P-256 key of the leaf. The leaf must
+carry the agent DID as a URI SAN. The agent never publishes a configured key; the operator
+publishes it under `assertionMethod` or `authentication` before startup. Keep the file out of
+source control, logs and image layers.
 
-Configured signing material uses a non-self-signed leaf, followed by any intermediates and the root. The private JWK must be the P-256 key matching the leaf. The values below are redacted and must be supplied through a secret-managed, read-only configuration file:
+### Development example
 
 ```json
-{
-  "signing": {
-    "configured": {
-      "certificateChain": [
-        "MIIB...REDACTED_LEAF_BASE64...",
-        "MIIC...REDACTED_INTERMEDIATE_BASE64...",
-        "MIIC...REDACTED_ROOT_BASE64..."
-      ],
-      "privateJwk": {
-        "kty": "EC",
-        "crv": "P-256",
-        "x": "REDACTED",
-        "y": "REDACTED",
-        "d": "REDACTED",
-        "alg": "ES256",
-        "kid": "issuer-signing-key"
-      }
-    }
-  },
-  "trust": {
-    "resolverUrl": "https://resolver.example/v1/trust",
-    "timeoutMs": 5000,
-    "allowedDidWebHosts": ["issuer.example"],
-    "credentialIssuerCertificates": ["MIIC...REDACTED_TRUSTED_ROOT_BASE64..."]
-  }
-}
+{}
 ```
 
-Apply the `signing` object under `issuer`, `verifier`, or both. Each leaf must contain the agent DID as a URI SAN, and its key must match the relevant DID relationship. The plugin never auto-publishes configured production keys; operators must publish them under `assertionMethod` or `authentication` themselves before startup. `credentialIssuerCertificates` contains verifier trust anchors, not peer-supplied chains. Each entry must parse as a currently valid, self-issued CA root with `keyCertSign`; duplicate roots are rejected. Do not put private JWKs in source control, logs, image layers, or public metadata.
-
-`allowedDidWebHosts` is the explicit network trust boundary for issuer DIDs read from verified certificates. Only exact `did:web` and `did:webvh` hosts on this operator-managed list are resolved. Do not populate it from a peer request or certificate. Credo owns the underlying fetch and redirect behavior, so an allowlisted host must have operator-trusted DNS and redirect behavior. Loopback, private, link-local, and unsupported DID targets are rejected before Credo resolution. Resolution returns after at most `timeoutMs`, which must not exceed 30000 milliseconds. The agent's own DID host is derived from `AGENT_PUBLIC_DID` and does not need to be repeated in this list.
+A file with no key at all runs both capabilities under development signing.
 
-### Configuration reference
+## Administration API
 
-| Field                             | Requirement                                                                                                                                                                                                                                  |
-| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `issuer`                          | Optional when `verifier` is present. Defines `id`, `displayName`, and exactly one signing mode.                                                                                                                                              |
-| `issuer.requireWalletAttestation` | Optional. When `true`, `walletAttestationCertificates` must contain locally configured X.509 roots. Trust-list distribution is not implemented.                                                                                              |
-| `verifier`                        | Optional when `issuer` is present. Defines `id`, `displayName`, and exactly one signing mode.                                                                                                                                                |
-| `trust`                           | Required by the verifier. Defines the HTTPS Verana resolver, a 1–30000 ms resolver timeout, exact allowed issuer DID web hosts, valid issuer CA roots, and optional development leaf fingerprints in `SHA256:` plus 64 lowercase hex format. |
-| `credentialConfigurations`        | Array of stable IDs, `dc+sd-jwt` format, VCT and VTJSC URLs, display fields, allowed claims, disclosure frame, and a 60–31,536,000 second lifetime.                                                                                          |
-| `verifierPolicies`                | Array mapping a policy ID to one credential configuration and a subset of its claims.                                                                                                                                                        |
+Every method lives under `/v2/openid4vc`, behind the Admin API authentication of the agent, and
+answers in the v2 error envelope. Without `OID4VC_CONFIG_FILE_LOCATION`, every path answers `404`.
 
-Claims named `vct`, `iat`, `exp`, `iss`, or `cnf` are reserved for the credential envelope and cannot be configured.
+| Method | Path | Notes |
+| --- | --- | --- |
+| `createCredentialOffer` | `POST /credential-offer` | `jsonSchemaCredentialId`, `claims`, `ttlSeconds` (60 to 7776000), optional `statusListId` and `statusListIndex` together. Returns `credentialExchangeId` and `url`. `404 UNKNOWN_ID`, `400 INVALID_INPUT`. Answers `UNKNOWN_ID` for every credential type until #711 and for every status list until #713. |
+| `listCredentialExchanges` | `GET /credential-exchanges` | Filters `jsonSchemaCredentialId`, `state`. Keyset pagination. |
+| `getCredentialExchange` | `GET /credential-exchanges/{credentialExchangeId}` | `credentialExchangeId`, `jsonSchemaCredentialId`, `state`, `createdAt`, `updatedAt`, `expiresAt`, `errorMessage`. Never the claims, the offer URL or the pre-authorized code. |
+| `deleteCredentialExchange` | `DELETE /credential-exchanges/{credentialExchangeId}` | `204`. Deletes the record only, never a credential that a wallet holds. |
+| `createPresentationRequest` | `POST /presentation-request` | `jsonSchemaCredentialId`, optional `requestedClaims` (defaults to every claim of the type), optional `queryLanguage` (`dcql`, `presentation_exchange`), optional `requestSigner` (`x5c`, `did`). Returns `proofExchangeId` and `url`. `404 UNKNOWN_ID`, `400 INVALID_INPUT`, `409 INVALID_STATE`. Answers `UNKNOWN_ID` for every credential type until #711. |
+| `listPresentations` | `GET /presentations` | Filters `jsonSchemaCredentialId`, `state`. Keyset pagination. |
+| `getPresentation` | `GET /presentations/{proofExchangeId}` | Adds the stored `jsonSchemaCredentialId` and `requestedClaims` of the request, then `cryptographicVerified`, `accepted`, `trust` and `credential` once the wallet answered. |
+| `deletePresentation` | `DELETE /presentations/{proofExchangeId}` | `204`. |
+| `listSigningCertificates` | `GET /signing-certificates` | Bare array of `role`, `development`, `fingerprint`, `certificateChain`. Never a private key. |
 
-## Route ownership
+Session states are credo's: `OfferCreated`, `OfferUriRetrieved`, `AuthorizationInitiated`,
+`AuthorizationGranted`, `AccessTokenRequested`, `AccessTokenCreated`, `CredentialRequestReceived`,
+`CredentialsPartiallyIssued`, `Completed`, `Error` for an issuance; `RequestCreated`,
+`RequestUriRetrieved`, `ResponseVerified`, `Error` for a verification.
 
-The control and protocol surfaces are intentionally separate.
+The agent stores `jsonSchemaCredentialId` and `requestedClaims` on the verification session when
+it creates the request, and never infers either from the response of the wallet. A list never
+decides: it reports the stored decision, and a verified session that nobody read yet shows
+`cryptographicVerified: true` and `accepted: false` without `trust`.
 
-| Surface        | Method and path                                                                           | Owner and purpose                                                                                                                                                            |
-| -------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Internal admin | `POST /v1/oid4vc/offers`                                                                  | Plugin controller. Creates a pre-authorized offer from `credentialConfigurationId` and all configured claims.                                                                |
-| Internal admin | `GET /v1/oid4vc/offers/:id`                                                               | Plugin controller. Returns safe issuance state only.                                                                                                                         |
-| Internal admin | `POST /v1/oid4vc/verifier/requests`                                                       | Plugin controller. Creates a request from `policyId`.                                                                                                                        |
-| Internal admin | `GET /v1/oid4vc/verifier/sessions/:id`                                                    | Plugin controller. Returns protocol state and the bounded trust result.                                                                                                      |
-| Internal admin | `GET /v1/oid4vc/certificates`                                                             | Plugin controller. Returns the configured roles' public signing certificates: leaf fingerprint (`SHA256:` pin format) and base64 chain. Never returns private keys.          |
-| Public         | `GET /oid4vc/vct/:configurationId`                                                        | Plugin route. Returns configured SD-JWT VC type metadata, extended with `relatedJsonSchemaCredentialId` (the ecosystem VTJSC) so wallets can verify schema governance and issuer/verifier accreditation through the Verana resolver. |
-| Public         | dynamic paths below `/.well-known/*`, `/oid4vci/:issuerId/*`, and `/oid4vp/:verifierId/*` | Pinned Credo router. Serves issuer/OAuth metadata, returned offer and request URIs, and wallet token, credential, authorization-request, and authorization-response traffic. |
+## Public endpoints
 
-Credo derives protocol paths from its current route configuration and record IDs. Wallets should follow the URIs returned by the admin API and metadata rather than constructing undocumented paths.
+Served on the public listener, without Admin API authentication. A wallet follows the URLs the
+Admin API and the metadata return; it never builds a path itself.
 
-The admin routes have the default `INTERNAL` access mode. They are absent from the public listener and unavailable through the corporation bearer-authenticated listener. The internal listener is network-trusted by default, so production deployments must isolate it or place it behind an authenticated reverse proxy. Credential offers are bearer capabilities and must not be logged or exposed through a public convenience endpoint.
+| Path | Purpose |
+| --- | --- |
+| `/.well-known/openid-credential-issuer`, `/.well-known/oauth-authorization-server`, `/.well-known/jwt-vc-issuer` | Issuer and authorization-server metadata, also at the path-inserted forms. |
+| `/oid4vci/issuer/...` | Token and credential traffic of the issuer capability. |
+| `/oid4vp/verifier/...` | Authorization request and response traffic of the verifier capability. |
 
 ## Trust decision
 
-A verifier accepts a presentation only after this sequence succeeds:
-
-1. Credo verifies the OpenID4VP response, nonce, audience, holder binding, SD-JWT disclosure, signature, and X.509 chain against configured roots or an exact development leaf pin.
-2. The plugin reads a DID only from a URI SAN after X.509 validation succeeds.
-3. Before network resolution, the DID must be a well-formed `did:web` or `did:webvh` on the operator allowlist, with no loopback, private, or link-local target. The resolved document ID must exactly match the requested DID.
-4. The certificate public key must match a verification method authorized by that DID document under `assertionMethod`. The plugin uses `authentication` for its own verifier request-signing certificate during startup.
-5. The Verana resolver must return `TRUSTED` for the issuer DID and authorize that issuer for the credential configuration's `vtjscId`.
-6. The result is accepted only for the exact `TRUSTED_AUTHORIZED` verdict.
-
-Missing or invalid chains, SAN errors, key mismatch, unresolvable DIDs, resolver timeout, malformed responses, non-`TRUSTED` status, and missing authorization all fail closed.
-
-## Verification evidence
-
-| Path                                                    | Evidence                                                                                                                                                                                                                                                |
-| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Pinned Credo `0.7.1-pr-2704-20260630143332`, in process | Automated issuance and presentation tests cover a pre-authorized offer, holder-bound `dc+sd-jwt`, DCQL, `x509_hash`, `direct_post.jwt`, `TRUSTED_AUTHORIZED` acceptance, DID-key mismatch, unauthorized issuers, resolver failure, and response replay. |
-| Android or EUDI wallet                                  | No live result, wallet version, or date is recorded for this foundation branch.                                                                                                                                                                         |
-| Official online interoperability tools                  | No result is recorded for this foundation branch.                                                                                                                                                                                                       |
-
-The automated path proves behavior between local Credo agents. It is not external-wallet evidence or formal conformance evidence.
+There is none yet. Nothing configures a resolver URL, allowed `did:web` hosts, credential-issuer
+roots or development fingerprints: the file rejects a `trust` block, and
+[#712](https://github.com/verana-labs/vs-agent/issues/712) builds the decision on the eight steps
+the spec now defines, on the indexer and on DID key binding, without one. Until it lands, a
+verified presentation answers `cryptographicVerified: true`, `accepted: false` and the verdict
+`RESOLVER_UNAVAILABLE`, and is never accepted.
+
+What the agent still enforces before that point: credo verifies the OpenID4VP response, the
+nonce, the audience, the holder binding, the SD-JWT disclosures and the signature, and the plugin
+fails a presented credential that carries no numeric `exp`. The session then ends in `Error`.
+
+## Wallet accommodations
+
+The public router adapts a few responses to specific wallets, each one scoped as narrowly as the
+wallet's behaviour allows: openid4vci-kt (EUDI reference wallet) accept header and
+`key_attestations_required`; swiyu plain-JSON metadata and closed `ProofType` enum; wwWallet
+`scope` and DPoP algorithms; NL Wallet certificate-bound signed metadata; MOSIP Inji EdDSA
+request signing under the parallel did:web and Presentation Exchange details. Each lives next to
+the code it changes, with a one-line note.
+
+## Tests
+
+`pnpm --filter @verana-labs/vs-agent-plugin-openid4vc exec vitest run` runs the unit tests and the
+in-process end-to-end tests, which start real credo agents for the issuer, the holder and the
+verifier and drive a pre-authorized issuance through to a stored holder-bound credential. The
+presentation round trip comes back with #712, which gives the verifier a trust anchor for the
+credential it receives. No external wallet or conformance evidence is recorded here; see the
+Verana Playground for recorded wallet scenarios.

package/build/config.d.ts

@@ -1,5 +1,14 @@
-import type { OpenId4VcCredentialConfiguration, OpenId4VcPluginOptions, OpenId4VcVerifierPolicy } from './types';
-export declare function validateOpenId4VcOptions(options: OpenId4VcPluginOptions): void;
+import type { OpenId4VcConfigurationFile, OpenId4VcCredentialConfiguration, OpenId4VcPluginOptions } from './types';
+export declare const ISSUER_CAPABILITY_ID = "issuer";
+export declare const VERIFIER_CAPABILITY_ID = "verifier";
+export declare const OFFER_TTL_SECONDS_MIN = 60;
+export declare const OFFER_TTL_SECONDS_MAX = 7776000;
+/** [VSA-VTI-CFG-ENV-OID] Validation of the OpenID4VC configuration file. */
+export declare function parseOpenId4VcConfiguration(document: unknown): OpenId4VcConfigurationFile;
 export declare function findCredentialConfiguration(options: Pick<OpenId4VcPluginOptions, 'credentialConfigurations'>, id: string): OpenId4VcCredentialConfiguration | undefined;
-export declare function findVerifierPolicy(options: Pick<OpenId4VcPluginOptions, 'verifierPolicies'>, id: string): OpenId4VcVerifierPolicy | undefined;
 export declare function parseOfferClaims(configuration: OpenId4VcCredentialConfiguration, input: unknown): Record<string, unknown>;
+export declare function parseOfferTtlSeconds(input: unknown): number;
+export declare function parseOfferIssuanceMetadata(configuration: OpenId4VcCredentialConfiguration, input: unknown): {
+    claims: Record<string, unknown>;
+    ttlSeconds: number;
+};