Verifier Queries - Revision history

Tom: /* Cred Acquisition Flow */

2025-06-28T00:58:32Z

‎Cred Acquisition Flow

Tom: /* mdoc network */

2025-06-27T23:44:36Z

‎mdoc network

Tom: /* References */

2025-06-27T23:37:24Z

‎References

Tom at 22:23, 27 June 2025

2025-06-27T22:23:28Z

Tom: /* OID4VP (presentation) */

2025-06-27T21:28:05Z

‎OID4VP (presentation)

Tom: /* Context */

2025-06-27T19:18:57Z

‎Context

Tom: Created page with "==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 owner..."

2025-06-27T18:27:13Z

Created page with "==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 owner..."

New page

==Full Title and Meme==
Digital Interchanges with human owned devices are becoming a negotiation between two [[Intelligent Agent]]s 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
==References==

[[Consent for Mobile Credentials]]
[[Digital Credential API]]

@@ Line 9: / Line 9: @@
 ==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`.
-. **Credential Offer Structure Validation**:
+# 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.
-   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`.
+# 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:
-. **Issuer Trustworthiness**:
+##   For `authorization_code`, it prepares for an OAuth 2.0 authorization flow.
-   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.
+##  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).
-. **Supported Credential Formats and Types**:
+# Security and Privacy Check**:  Depending on implementation, the wallet might:
-   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.
+##  Check for replay attacks by validating `issuer_state` or nonce values.
+##  Ensure no sensitive data is exposed prematurely.
-. **Grant Type Handling**:
+##  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.
 * [https://docs.walt.id/community-stack/wallet/api/credentials/guides/receive-and-store-vc-oid4vci How to Store W3C Verifiable Credentials (JWT / SD-JWT) in a Wallet with walt.id]
 ==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:

@@ Line 77: / Line 77: @@
 Next dig into how wallets handle different credential formats here—like SD-JWT-VP vs. JWT VC vs. ZKP.
 ===mdoc network===
@@ Line 135: / Line 137: @@
 ---
-This flow ensures **cryptographic integrity**, **user consent**, and **privacy-preserving attribute sharing**. If you’d like, I can 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.
+This flow ensures **cryptographic integrity**, **user consent**, and **privacy-preserving attribute sharing**.
 ===mdoc in-person===

← Older revision		Revision as of 23:37, 27 June 2025
Line 77:		Line 77:

	Next dig into how wallets handle different credential formats here—like SD-JWT-VP vs. JWT VC vs. ZKP.		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. If you’d like, I can 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?

	==References==		==References==

@@ Line 7: / Line 7: @@
 permission not identity
-==FLow==
+==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:
@@ Line 76: / Line 76: @@
 This ensures verifiable presentations are both **cryptographically sound** and **privacy-preserving**, aligning with the least-privilege principle.
-If you'd like, we can dig into how wallets handle different credential formats here—like SD-JWT-VP vs. JWT VC vs. ZKP.
+Next dig into how wallets handle different credential formats here—like SD-JWT-VP vs. JWT VC vs. ZKP.
 ==References==

@@ Line 35: / Line 35: @@
 Once these checks pass, the wallet proceeds to initiate the credential acquisition flow, typically by exchanging tokens or codes with the issuer.
 * [https://docs.walt.id/community-stack/wallet/api/credentials/guides/receive-and-store-vc-oid4vci How to Store W3C Verifiable Credentials (JWT / SD-JWT) in a Wallet with walt.id]
-===OID4VP (presentation)===
+==OID4VP (presentation)==
-Great—let’s 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:
+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===
 . **Presentation Definition Validation**

@@ Line 6: / Line 6: @@
 permission not identity
 ==References==
 [[Consent for Mobile Credentials]]
 [[Digital Credential API]]