Citizen Services

Apply for a residence certificate

Checking this browser

Identity required

Sign in to Citizen Services

Use your EUDI Wallet to prove who you are before continuing to the service.

Step 2 of 3Confirm your identity

Residence certificate

Identity check required before personal records are shown.

Family nameGiven nameDate of birthCurrent address

ServiceResidence certificate

Sign-in methodEUDI Wallet

Details requestedFamily name, given name, birth date, current address

Preparing sign-in code

OID4VP request and wallet exchange

Protocol, cryptography, and data flow

The same technical view is available for every sign-in variant. It describes the request before a wallet responds and the exact signing keys observed after a presentation is verified.

Awaiting a presentation

Request format

Choose what the wallet should presentThis selection changes the DCQL credential query and regenerates the QR request. The wallet cannot switch formats after scanning unless the request explicitly declares both formats as DCQL alternatives.

Live presentation trace

OID4VP protocol state

creating nonce

1
Request preparedready
OpenID4VP request for dc+sd-jwt / SD-JWT+KB with 4 requested claims.
Nonce
creating
QR transport
openid4vp:// → direct_post
Same-device transport
not active
2
Wallet presentationwaiting
Scan the QR code or start the wallet request to begin.
Holder proof
awaiting SD-JWT cnf.jwk
Holder key format
awaiting cnf.jwk
Response protection
signed presentation over direct_post
Response envelope
awaiting wallet response
Data returned
not received
3
Verifier processingwaiting
Verification starts after the wallet response arrives.
Issuer signature
awaiting issuer JWS / COSE proof
Issuer key format
awaiting issuer JWK / x5c
Credential
awaiting issuer claims
Disclosure binding
awaiting SD-JWT disclosures
Response parameters
awaiting wallet response
Holder signature
awaiting holder binding proof
Nonce check
awaiting holder binding proof
Audience check
awaiting holder binding proof
Issued-at check
not applicable to mdoc
sd_hash check
not applicable to mdoc
Output
no presentation output yet

Copyable Markdown assessment

Standards compliance report

Generated from this request and the verifier's observed result. It avoids PID values and full public-key material so it can be shared with a wallet engineering task.

Compliance checklist and evidence

SD-JWT VC / OpenID4VP Standards-Compliance Report

Assessment result

Outcome: PENDING — no presentation has been verified yet
Scope: OpenID for Verifiable Presentations 1.0; RFC 9901 SD-JWT; SD-JWT VC profile; ML-DSA and classic JOSE signatures
Credential requested: dc+sd-jwt, vct=urn:eudi:pid:1
Transport observed/requested: direct_post / QR
Trust boundary: cryptographic verification is enabled; issuer authorization, PKI chain trust, certificate validity/revocation, status-list resolution, and trust-list policy are intentionally NOT checked
Failure evidence: none

OpenID4VP request profile

response_type=vp_token
DCQL Credential Query id is pid_sd_jwt and format is dc+sd-jwt
require_cryptographic_holder_binding=true
Requested claims are unique and use JSON claim paths; the mdoc-only intent_to_retain is not sent for SD-JWT
Verifier advertises issuer and KB-JWT algorithms: ML-DSA-44/65/87, ES256/384/512, EdDSA, RS256/384/512, and PS256/384/512
Nonce/session value is generated with 144 random bits: not generated
QR flow uses client_id=redirect_uri:<response_uri>, response_mode=direct_post, and an exact state value
Same-device unsigned DC API request uses response_mode=dc_api, omits client_id, and returns the Authorization Response object in DigitalCredential.data
KB-JWT audience is origin:<verifier-origin>

Requested claims: family_name, given_name, birthdate, address

Authorization Response checklist

NOT ESTABLISHED — direct_post body is UTF-8 application/x-www-form-urlencoded
NOT ESTABLISHED — state is present and exactly matches the verifier session
NOT ESTABLISHED — vp_token is a DCQL-keyed JSON object containing exactly one pid_sd_jwt array entry and one Presentation
NOT ESTABLISHED — the presented credential contains every requested DCQL claim
NOT ESTABLISHED — the successful direct_post session is configured as one-time and replay protected

SD-JWT VC and JOSE checklist

NOT ESTABLISHED — Complete SD-JWT issuer, disclosure, and holder-binding cryptographic evidence is present
NOT ESTABLISHED — Issuer JWS is compact, signed, and uses protected typ=dc+sd-jwt
NOT ESTABLISHED — Issuer algorithm is an allowed ML-DSA or classic JOSE algorithm
NOT ESTABLISHED — Issuer verification key has exactly one unambiguous source (public AKP JWK or x5c leaf)
NOT ESTABLISHED — Disclosures are valid UTF-8 JSON, canonically base64url encoded, digest-bound, unique, connected, and collision-free
NOT ESTABLISHED — Undisclosed and decoy digests are ignored as required by RFC 9901
NOT ESTABLISHED — Reserved SD-JWT VC claims are not selectively disclosed and _sd_alg occurs only at top level
NOT ESTABLISHED — Holder key is taken from the issuer-signed cnf.jwk and is a public ML-DSA, EC, OKP, or RSA verification key
NOT ESTABLISHED — KB-JWT signature verifies with the cnf.jwk key and protected typ=kb+jwt
NOT ESTABLISHED — KB-JWT nonce matches this transaction
NOT ESTABLISHED — KB-JWT aud is one exact string for this verifier
NOT ESTABLISHED — KB-JWT iat is within the verifier freshness window
NOT ESTABLISHED — KB-JWT sd_hash matches the exact presented SD-JWT and disclosures
NOT ESTABLISHED — unsupported JOSE critical headers, unencoded payloads, ambiguous keys, private JWK material, and invalid key/signature lengths are rejected

Observed cryptography and keys

Issuer proof: not observed
Issuer public key: Not observed because verification did not complete.
Holder proof: not observed
Holder public key: Not observed because verification did not complete.
Disclosure hash: not observed
Disclosure count: not observed
KB-JWT nonce: not observed
KB-JWT audience: not observed
KB-JWT issued-at: not observed
KB-JWT sd_hash: not observed
Response body encoding evidence: not observed
Response state evidence: not established
Response shape: not observed
Response parameters: not observed

Verifier-enforced ambiguity and violation checks

Duplicate JSON object member names are rejected before JSON materialization.
Duplicate form parameters, disclosure digests, salts, embedded digest references, and colliding disclosed claim names are rejected.
Non-canonical base64url, invalid UTF-8, malformed compact JWS/SD-JWT+KB, nested _sd_alg, illegal ... placeholders, and unreferenced disclosures are rejected.
Unknown Authorization Response parameters are ignored as required by OpenID4VP; extra DCQL credential-map entries are rejected because this request contains exactly one mandatory Credential Query with multiple=false.
Issuer and holder signatures are verified using the observed ML-DSA or classic JOSE algorithm, with strict protected-header/key matching.

Standards references

Wallet remediation instructions for Codex

Wallet Remediation Brief for Codex

Objective

Make the wallet produce an SD-JWT VC presentation that the verifier accepts under OpenID4VP 1.0, RFC 9901, the SD-JWT VC profile, and RFC 9964. Do not weaken verifier checks to accommodate malformed output.

Observed result

Result: PENDING — no presentation has been verified yet
Verifier evidence: No presentation has been observed yet.
Requested claims: family_name, given_name, birthdate, address
Expected credential: vp_token.pid_sd_jwt[0] containing one dc+sd-jwt SD-JWT+KB string

Required wallet output contract

Return the OpenID4VP Authorization Response in the requested response mode.
For direct_post, POST UTF-8 application/x-www-form-urlencoded with one state and one vp_token parameter.
Encode vp_token as {"pid_sd_jwt":["<Issuer-JWS>~<Disclosure>~...~<KB-JWT>"]}; do not return a bare string, extra credential ids, or multiple presentations.
Use issuer protected header typ=dc+sd-jwt and an advertised alg: ML-DSA-44/65/87, ES256/384/512, EdDSA, RS256/384/512, or PS256/384/512.
Represent public keys with the matching public JWK family: AKP pub for ML-DSA, EC x/y for ES*, OKP x for EdDSA, or RSA n/e for RS*/PS*. Never send private key material.
Put the holder public JWK in the issuer-signed cnf.jwk. Sign the KB-JWT with the corresponding private key; do not put a competing jwk or x5c in the KB-JWT header.
Use KB-JWT protected typ=kb+jwt; include string nonce, single-string aud, NumericDate iat, and exact sd_hash over <Issuer-JWS>~<selected-disclosure>~...~.
Return every requested DCQL claim and no unselected selectively disclosable claims. Keep iss, nbf, exp, cnf, vct, vct#integrity, and status out of Disclosures.
Use unique salts and digest references. Permit undisclosed/decoy digests to remain unmatched; do not send an unreferenced Disclosure.
Preserve exact state, nonce, audience, compact serialization, base64url encoding, and JSON member uniqueness.

Suggested Codex work sequence

Capture the wallet's raw Authorization Response before transport encoding.
Add unit tests that assert the exact DCQL map and SD-JWT+KB combined serialization.
Decode both JOSE protected headers and payloads without changing bytes; compare them to the contract above.
Verify issuer and holder signatures locally with the advertised ML-DSA or classic JOSE algorithm and exact key/curve parameters.
Recompute every Disclosure digest and the KB-JWT sd_hash from the original encoded strings.
Add negative tests for duplicate members, wrong typ, array-valued aud, stale iat, nonce/audience mismatch, extra presentations, private JWK material, and disclosure collisions.
Re-run against a fresh verifier QR request because state/nonce sessions are one-time.

Questions for the wallet implementation

Does the wallet currently return a bare SD-JWT string instead of the DCQL-keyed vp_token object?
Which exact protected typ values are emitted for the issuer JWS and KB-JWT?
Is the issuer key embedded as jwk or x5c, and can both appear at once?
Is cnf.jwk byte-for-byte the public key corresponding to the KB-JWT signing key?
Is aud redirect_uri:<response_uri> for QR/direct_post and origin:<origin> for DC API?
Are response parameters form encoded once, without duplicate names or nested stringification?
Are any validity, type, confirmation, or status claims being selectively disclosed contrary to the SD-JWT VC profile?
Can the wallet export a failing raw response plus decoded JOSE headers/payloads without private keys or PID values for comparison?

Acceptance criteria

The verifier report changes to PASS.
Issuer signature, Disclosure processing, holder signature, nonce, audience, iat, sd_hash, response shape, requested claims, and replay checks all show PASS.
No trust result is claimed; trust remains explicitly outside this demo's scope.

Show request, protocol, and key reference details

Credential formatdc+sd-jwt / SD-JWT+KB

TransportOpenID4VP / direct_post

Trust policyCryptographic checks on · trust checks skipped

What the QR code carries

OpenID4VP authorization request

URI scheme: openid4vp://
Response mode: direct_post → this verifier callback
Credential query: dc+sd-jwt · urn:eudi:pid:1
Requested claims: Family name · Given name · Date of birth · Current address
QR request size: Preparing request

Wallet communication

High-level exchange

1Verifier creates a nonce, claim query, response URI, and—when using DC API—an ephemeral P-256 encryption key.
2QR scan opens the OpenID4VP request in the wallet; the wallet evaluates the selected DCQL format.
3Wallet sends a presentation to the direct_post callback. The browser polls the short-lived session.
4Verifier decrypts the response when needed, then checks signatures and binding values.

Data transmitted

Only request context before approval

Sent to the walletCredential format, requested claim names, nonce, verifier callback, and supported algorithms; DC API also carries a response-encryption public key.

Returned by the walletA presentation containing only the approved claims, plus issuer and holder proofs. The QR code never contains PID values or private keys.

Kept for the demo sessionA short-lived server-side response keyed by the nonce so the scanning phone can return to this browser.

Issuer signature

Allowed issuer algorithms

Algorithms requested: ML-DSA-44 · ML-DSA-65 · ML-DSA-87 · ES256 · ES384 · ES512 · EdDSA · RS256 · RS384 · RS512 · PS256 · PS384 · PS512
Key source: JWK or x5c in issuer JWS
Key type: AKP
Public key size: Shown after verification

Holder binding

Allowed holder algorithms

Algorithms requested: ML-DSA-44 · ML-DSA-65 · ML-DSA-87 · ES256 · ES384 · ES512 · EdDSA · RS256 · RS384 · RS512 · PS256 · PS384 · PS512
Key source: cnf.jwk in SD-JWT
Key type: AKP
Public key size: Shown after verification

Verification checks

SD-JWT+KB checks

Issuer JWS signature (ML-DSA or classic JOSE)Holder Key Binding JWT signature (ML-DSA or classic JOSE)SD-JWT disclosure digestsNonce, audience, iat, and sd_hash binding

Disclosure hash: SHA-256 default (SHA-384 and SHA-512 accepted)

Observed issuer key

The issuer public key appears here after the presentation is verified.

Observed holder key

The holder key appears here after the SD-JWT+KB is verified.

Response encryption key

No response-encryption JWK in the QR request

QR uses direct_post and does not put a response-encryption JWK in the QR payload. The presentation remains integrity-protected by the issuer and holder signatures. Same-device requests use the unencrypted dc_api response mode.