Verifier Queries

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:

1. **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`.

2. **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.

3. **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.

4. **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.

5. **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).

6. **Security and Privacy Checks**:

  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.

• 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:

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.

References

Consent for Mobile Credentials Digital Credential API