Credentials — field reference¶

Status: 23 October 2026, contract v3. Every credential in the Scoped Mandate PoC, field by field: what each field means, who sets it, who checks it. The field tables on this page are machine-checked: the bank smokes compare them with credentials that bank and operator actually issue, and fail when a field is missing here or documented but no longer issued (see Keeping this page current).

Overview¶

Two further signed objects belong to the picture but are not credentials: the checkout part, which the mandate credential commits to by hash, and the status list, through which issuers revoke. How a holder proves possession of its key when a credential is issued is in proof JWT. Since 2026-10-25 the bank also signs every executed payment: the payment confirmation is the token with which the agent completes a UCP checkout.

Common format¶

All three credentials are SD-JWT VCs (dc+sd-jwt): <issuer JWT>~<disclosure>~…~ and, when presented, a key-binding JWT appended at the end.

• The issuer JWT is signed with ES256 by the issuer's certificate; the header carries the chain (x5c) to the issuer's root (/issuer/root.pem at bank and operator).
• Claims marked selectively disclosable are not in the payload. The payload holds only their digests in _sd; the values travel as separate disclosures [salt, name, value], and the holder decides which disclosures to present.
• Times without a date format are Unix seconds (iat, nbf, exp); dates in claims are ISO 8601 UTC. Amounts are integer cents.
• Issuers keep a readable copy of every credential they issued since 23 October 2026 — header, payload and disclosed claims, without signature and salts — behind Details in the bank dashboard and the operator portal (GET /issuer/credentials/{id}).

The header is the same for all three credentials:

1. Konto Karte¶

The customer's bank card in the wallet: identity and login at the bank. With it the customer approves mandates (strong customer authentication in the PaSO profile) and identifies to the agent's operator.

Payload¶

Selectively disclosable¶

Presentation¶

The wallet appends a key-binding JWT (typ: kb+jwt), signed with the key in cnf.jwk, after Face ID.

Key-binding JWT to the bank for the mandate approval (PaSO Core §6.1 plus key binding):

2. Agent credential¶

The shopping agent's identity, issued by its operator. It ties the agent key to a legal person that is accountable for the agent. In the target picture it comes from the operator's European Business Wallet.

Payload¶

Selectively disclosable¶

The operator also records who onboarded the agent (the Konto Karte's name and customer reference). That stays in the operator's register; it is not in the credential.

Presentation¶

The agent signs the key-binding JWT with the agent key; no Face ID.

3. Mandate credential¶

The approved mandate itself, issued by the bank to the agent key (contract v3). It carries the payment part in the clear and commits to the checkout part by hash. The bank keeps the mandate; this credential is its portable proof.

Payload¶

Selectively disclosable¶

Presentation¶

Only to the merchant, by the agent, together with the agent credential and the checkout part in the clear (§2.5): <issuer JWT>~<key-binding JWT> — no disclosures. Key-binding JWT signed with the agent key: nonce, aud = merchant id, iat, sd_hash (over exactly the presented <issuer JWT>~), transaction_data_hashes (the basket entry), transaction_data_hashes_alg; jti is recorded if present.

4. Checkout part (not a credential)¶

The product rules of the mandate. Built by the wallet, shown to the customer next to the payment part, signed by nobody: its hash went into the approved transaction_data (signed by the Konto Karte key) and into the mandate credential (signed by the bank). Held by wallet and agent, sent to the merchant in the clear at every purchase, kept in the merchant's log. The bank never sees it.

Hash C = sha256: + hex SHA-256 over the canonical JSON of exactly these fields (sorted keys, no whitespace, / not escaped). Categories are Google Product Taxonomy IDs (Interface Specification §1.10.2: matching rule, legacy words). Legacy v2 checkout parts additionally carried principal_key, signature and a credential form urn:digitallabor:checkout_mandate:1 signed by the customer; the merchant still accepts them from app builds ≤ 792.

5. Status list token¶

How issuers revoke: one bit per credential, served as a signed token at /issuer/status/1 (bank and operator each have their own). Verifiers fetch it and check the bit at status.status_list.idx.

Header: alg ES256, typ statuslist+jwt, kid, x5c (bound to the host of the list).

6. Proof JWT (issuance)¶

When a wallet or the agent redeems an offer, it proves possession of the key the credential will be bound to. Header: alg ES256, typ openid4vci-proof+jwt, jwk = the holder's public key (becomes cnf.jwk). Payload: iss (client id: wallet-dev for the wallet, eudipal-agent for the agent), aud = the issuer URL, iat, nonce from /issuer/nonce (single use). For the mandate credential the bank additionally requires jwk to be the mandate's agent key.

7. Payment confirmation (UCP token)¶

Not a credential: a compact JWS the bank returns with every executed payment (POST /payments → confirmation). The agent hands it to the merchant as payment.instruments[0].credential.token of the UCP payment handler de.digitallabor.bank_push; the merchant verifies it against the bank root without calling the bank (Interface Specification §2.6).

Keeping this page current¶

The tables between the markers <!-- fields:… --> and <!-- /fields --> are read by tools/mock-bank/credential_docs.py. The bank smokes call it with the credentials they actually obtain:

A smoke fails when an issued field is not documented here (a nested field is covered by a documented parent, e.g. cnf.jwk covers cnf.jwk.x), or when a field documented as always is missing in the issued credential. Changing a credential therefore means changing this page in the same commit.