Skip to content

OID4VC Protocol Integration

Overview

This document describes how Access Certificates and Registration Certificates are integrated into the OpenID for Verifiable Credentials (OID4VC) protocol family for issuance and presentation flows.

Normative Standards

The technical specifications are defined in ETSI standards:

  - **ETSI TS 119 472-2**: Presentation requirements
  - **ETSI TS 119 472-3**: Issuance requirements
  - **ETSI TS 119 411-8**: Access Certificates
  - **ETSI TS 119 475**: Registration Certificates

For details on the certificates themselves, see Wallet-Relying Party Authentication.

Design Principle: Privacy-Preserving Direct Inclusion

Certificates are included directly in requests rather than being fetched from the Registrar. This design:

  • Preserves privacy: The Registrar cannot monitor which Wallet interacts with which RP
  • Supports offline use: No real-time connection to Registrar required
  • Reduces latency: No additional round-trips during the flow

The Wallet only contacts the Registrar to fetch revocation status (CRL or Status List), which does not reveal the specific transaction.

Credential Issuance (OID4VCI)

Before issuing a credential to a Wallet, the issuer must authenticate itself.

Flow Overview

EUDI Wallet.Q.EAA ProviderRegistrarEU Trust AnchorEUDI WalletEUDI Wallet(Q)EAA Provider(Q)EAA ProviderRegistrarRegistrarEU Trust AnchorEU Trust AnchorPeriodically fetch trust anchorFetch EU List of RegistrarsTrust anchor listRequest Credential IssuerMetadataSigned metadata with AccessCertificateValidate issuer identity(chain of trust)Fetch CRL / Status ListRevocation statusProceed if valid

Key Steps

  1. Trust anchor: Wallet maintains an up-to-date EU List of Registrars
  2. Metadata request: Wallet fetches Credential Issuer Metadata
  3. Issuer authentication: Metadata is signed; Access Certificate included
  4. Validation: Wallet validates the certificate chain of trust
  5. Revocation check: Wallet fetches CRL from Registrar
  6. Decision: Process continues only if all validations pass

Credential Presentation (OID4VP)

When requesting a credential presentation, the RP must authenticate and declare its intended use.

Flow Overview

UserWalletRelying PartyRegistrarUserUserWalletWalletRelying PartyRelying PartyRegistrarRegistrarTrust anchor already cachedCreate presentation requestSend request with certificatesAccess + RegistrationCertificates attachedValidate RP identityValidate intended use(over-asking check)Fetch revocation statusCRL / Status ListDisplay RP info and purposeApprove presentationSend presentation response

Key Steps

  1. Request creation: RP creates presentation request signed with Access Certificate key
  2. Certificate inclusion: Both Access Certificate and Registration Certificate(s) are attached to the request
  3. RP authentication: Wallet validates the Access Certificate chain
  4. Intended use validation: Wallet compares request against Registration Certificate
  5. Revocation check: Wallet fetches status from Registrar
  6. User consent: Wallet displays RP identity and purpose; user approves
  7. Response: Wallet sends presentation to RP

Over-Asking Protection

The Wallet validates that the requested attributes are within the scope declared in the Registration Certificate:

  • Requested credentials must be a subset of registered credentials
  • Requested claims must be a subset of registered claims
  • If validation fails, user is warned but may choose to proceed

Certificate Attachment

Certificates are attached to requests according to ETSI specifications:

Certificate Type Purpose Specification
Access Certificate RP authentication ETSI TS 119 411-8
Registration Certificate Intended use declaration ETSI TS 119 475

The technical format for attaching certificates to OID4VP/OID4VCI requests is defined in the respective ETSI standards.

Proximity Flow

For proximity (offline) scenarios, the same principles apply:

  • Certificates are included directly in the request
  • Validation occurs locally on the device
  • Revocation status may be checked when connectivity is available
  • User consent is always required