Verifier Queries
Contents
Full Title and Meme
Digital Interchanges with human owned devices are becoming a negotiation between two Intelligent Agents each with their own set of beneficial owners.
Context
By 2025 many sovereign states and corporations (with aspirations to become sovereign) have issued a variety of digital credential to their residents.
permission not identity
Cred Acquisition Flow
When a wallet receives a credential offer in the OpenID for Verifiable Credential Issuance (OID4VCI) flow, it performs a series of checks before proceeding with credential acquisition. Here's a breakdown of the key validations:
- Credential Offer Structure Validation**: The wallet parses the `credential_offer` object (often embedded in a URL) to ensure it conforms to the expected JSON structure. This includes verifying fields like `credential_issuer`, `credentials`, and `grants`.
- Issuer Trustworthiness**: The wallet checks whether the `credential_issuer` is trusted. This may involve verifying the issuer’s metadata, checking digital signatures, or consulting a trust registry or allowlist.
- Supported Credential Formats and Types**: It confirms that the credential formats (e.g., `jwt_vc_json`, `ldp_vc`, `sd-jwt-vc`) and types offered are supported by the wallet. Unsupported formats are typically rejected or flagged for user review.
- Grant Type Handling**: The wallet examines the `grants` section to determine how to obtain the credential:
- For `authorization_code`, it prepares for an OAuth 2.0 authorization flow.
- For `pre-authorized_code`, it checks for the presence of a valid code and whether a user PIN is required.
- Credential Definition Consistency**: The wallet may validate that the `credential_definition` aligns with known schemas or expected contexts (e.g., W3C VC Data Model contexts).
- Security and Privacy Check**: Depending on implementation, the wallet might:
- Check for replay attacks by validating `issuer_state` or nonce values.
- Ensure no sensitive data is exposed prematurely.
- Log or sandbox the offer for user consent before proceeding.
Once these checks pass, the wallet proceeds to initiate the credential acquisition flow, typically by exchanging tokens or codes with the issuer.
OID4VP (presentation)
Follow the thread from issuance to presentation in the OpenID for Verifiable Presentations (OID4VP) flow. Here’s what happens once the wallet holds a verifiable credential (VC) and receives a presentation request:
Wallet Checks Upon Receiving a Presentation Request
1. **Presentation Definition Validation**
The wallet verifies that the request contains a valid [presentation definition](https://identity.foundation/presentation-exchange/) (typically using the Presentation Exchange specification). This includes constraints on: - Credential type, format, or schema - Required claims (e.g., birthdate, degree) - Submission requirements (e.g., pick one from a group)
2. **Requester Authentication and Trust Evaluation**
- The wallet evaluates the **verifier’s identity** (the `client_id` in OIDC parlance). - If the verifier isn't on an allowlist or doesn't support signed requests or metadata, the wallet may reject the request or prompt the user.
3. **Request Signature and Nonce Verification**
- For **signed presentation requests** (often via `request_object`), the wallet checks the request’s JWT signature, issuer, expiration, and audience. - It validates the `nonce` to ensure replay protection, often tying it to a session or binding to the proof in the presentation.
4. **Credential Selection and Filtering**
Based on the constraints in the presentation definition, the wallet: - Filters stored credentials for matches - May auto-select or prompt the user to choose which credentials to present - Checks if selective disclosure or minimal disclosure can be applied (especially with SD-JWTs or ZKP-based formats)
5. **User Consent and Review**
The wallet should present a **consent screen**, showing: - What data is being shared - Who is requesting it - Any risks or implications
6. **Presentation Construction and Proof Binding**
- The wallet constructs a verifiable presentation matching the requested definition. - It cryptographically binds the presentation to the verifier’s `nonce` (often using the `vp_token`) to ensure integrity and prevent reuse.
7. **Transmission to the Verifier**
The wallet sends the presentation via `vp_token` (OIDC authorization response or POST), optionally including an `id_token` or `presentation_submission` describing the mapping between inputs and constraints.
---
This ensures verifiable presentations are both **cryptographically sound** and **privacy-preserving**, aligning with the least-privilege principle.
Next dig into how wallets handle different credential formats here—like SD-JWT-VP vs. JWT VC vs. ZKP.
mdoc network
Here’s a high-level view of the **network flow for an mDL (mobile driver’s license) presentation** using the ISO/IEC 18013-5 and -7 standards, especially in a remote web verification scenario (e.g. OpenID4VP over HTTP):
---
- 📲 1. **Presentation Request Initialization**
- The **verifier** (e.g. a bank’s web app) initiates a session using a **Verifier SDK**. - It generates a **presentation request** (e.g. via OpenID4VP or ISO 18013-7) and encodes it in a QR code or deep link.
---
- 📡 2. **Wallet Engagement**
- The **user scans the QR code** or clicks the link, triggering their **wallet app**. - The wallet parses the request and evaluates:
- The verifier’s identity and trustworthiness - The request’s nonce, audience, and expiration - The requested attributes and constraints
---
- 🔐 3. **User Consent & Credential Selection**
- The wallet displays:
- What data is being requested (e.g. name, birthdate) - Who is requesting it
- The user selects which mDoc(s) to share and consents.
---
- 🧾 4. **Presentation Construction**
- The wallet constructs a **Verifiable Presentation**:
- Includes requested attributes from the mDL - Binds the presentation to the verifier’s nonce - Signs the presentation (e.g. using device-bound keys or issuer-signed proofs)
---
- 🚀 5. **Transmission to Verifier**
- The wallet sends the presentation to the verifier:
- Via `vp_token` in an OpenID response (if using OID4VP) - Or via a POST to the verifier’s endpoint (ISO 18013-7 flow)
---
- 🧠 6. **Verifier Validation**
- The verifier:
- Validates the signature and nonce binding - Checks credential integrity and issuer trust - Maps the presentation to the original request (via `presentation_submission` or session transcript)
---
- ✅ 7. **Result Handling**
- If valid, the verifier proceeds with the business logic (e.g. account creation). - If not, the user is notified and may retry or escalate.
---
This flow ensures **cryptographic integrity**, **user consent**, and **privacy-preserving attribute sharing**.
Nex sketch out the same-device flow (e.g. NFC or Bluetooth-based mDL presentation) or dive into how Apple’s HPKE-based mDL flow differs.
mdoc in-person
Here’s a breakdown of the **in-person wireless presentation flow** for an mDL (mobile driver’s license) or mDoc, based on ISO/IEC 18013-5 and 18013-7 standards. This typically uses **BLE (Bluetooth Low Energy)** or **NFC** for device-to-device communication—no internet required:
---
- 🔄 1. **Session Initiation**
- The **verifier device** (e.g. a police officer’s tablet) starts a **Device Engagement (DE)** process. - It broadcasts a **Device Engagement message** via BLE or NFC, containing:
- Session transcript data - Supported protocols and security parameters
---
- 📲 2. **Wallet Discovery and Connection**
- The **holder’s wallet app** detects the DE message and initiates a secure connection. - A **secure session** is established using **Ephemeral Diffie-Hellman key exchange** (ECDHE), often with **Device Authentication** (e.g. X.509 certs or mdoc authentication keys).
---
- 🔐 3. **Request for Data**
- The verifier sends a **Device Request**:
- Specifies requested attributes (e.g. name, DOB, license class) - Includes a **nonce** and **session transcript hash** for binding - May include a **reader certificate** to prove verifier identity
---
- 👤 4. **User Consent**
- The wallet displays:
- Requested data - Verifier identity (if available)
- The user **approves or denies** the request.
---
- 🧾 5. **Data Retrieval and Signing**
- The wallet retrieves the requested attributes from the mDL/mDoc. - It constructs a **Device Response**:
- Includes signed attributes (issuer-signed or device-signed) - Binds the response to the verifier’s nonce and session
---
- 📡 6. **Response Transmission**
- The Device Response is sent back to the verifier over the secure BLE/NFC channel. - The response may include:
- **Issuer-signed data elements** - **Device signature** (if using device-signed mode) - **Session binding proof**
---
- 🧠 7. **Verifier Validation**
- The verifier:
- Validates the signature(s) - Checks issuer trust (e.g. via certificate chain) - Verifies nonce/session binding - Extracts and uses the attributes
---
This flow is **offline-capable**, **privacy-preserving**, and **cryptographically secure**. It supports **selective disclosure**, meaning only the requested data is shared—no more, no less.
Want to compare this with Apple’s HPKE-based mDL flow or explore how ISO 23220 expands this to other mDoc types?
