WG Discussion Paper: eKYC Format-Agnostic Digital Identity Claims & Values for Cross-Sector Compliance & Examiner Defence

Date: March 2, 2026
Status: DRAFT for Working Group Review
Subject: Format-Agnostic Digital Identity for Cross-Sector Compliance & Examiner Defense
Author: Juliana Cafik
Audience: OIDF Digital Credentials Protocols (DCP) WG, eKYC/IDA WG

1. Purpose

Verifiable Digital Credentials (VDCs), such as mobile driver’s licenses (mDLs), are an emerging technology that can improve current know your customer (KYC) processes. However, to transition to this new form of identity evidence, relying parties require greater clarity around the assurance of the credential being presented and the functional ability to collect the information necessary to satisfy stringent compliance, risk management and audit requirements. To address these needs, this discussion paper proposes a globally interoperable framework that defines identity claims designed to support high-assurance KYC processes and the use of VDCs as identity evidence. By defining standardized claims the framework empowers institutions to execute enhanced, runtime risk decisions aligned to the risk profile of a specific transaction or account type. To meet stringent examiner scrutiny, the framework ensures standardized claims and parameter values for defensible audit trails, providing institutions with clear machine-readable evidence of what was verified and the cryptographic proof necessary to seamlessly fulfill ongoing recordkeeping mandates.

Threat Mitigation Consideration: The architectural requirements defined herein, specifically outline the cryptographic holder binding and the transmission of raw binary evidence as foundational artifacts for KYC but also provide defences against a rapidly expanding attack surface. As threat actors deploy hyper-efficient, agentic AI-driven deepfakes and scaled synthetic identity injections, relying on semantic strings (e.g., asserting a face was checked) is inadequate. This proposed profile also proposes to enforce mathematical, cryptographic proof to secure the ecosystem against next-generation automated exploitation.

2. Scope

This paper proposes a protocol, format, and jurisdiction-agnostic framework for identity claims that extends the: OpenID Identity Assurance Schema Definition 1.0 and OpenID Connect for identity Assurance Claims Registration 1.0 to directly support Relying parties (RPs) in establishing a legally defensible “reasonable belief” of customer identity. It introduces a standardized parameter registry with defined URNs and normalizes the claims required for institutions to capture and maintain rigorous, examiner-ready requirements. It addresses claims provenance, distinguishing between issuer-attested and wallet-asserted claims to facilitate dynamic, risk-based decisioning during the onboarding process. Additionally, the framework covers security considerations for claim verification to mitigate advanced presentation threats.

3. Protocol and Format Agnosticism

Previous iterations of identity schema mapping created friction by forcing format collisions (e.g., attempting to translate binary CBOR/COSE mDL data into plaintext JSON/JOSE arrays), which inherently breaks the trusted credential issuer's digital signature.

To achieve true format agnosticism, implementations MUST separate theTrust Establishment Layer (the registry/VICAL), the Metadata Envelope (the compliance vouching protocol), and the Cryptographic Payload (the native evidence).

• Transport Layer Agnostic: Supports ISO 18013-5/7, OpenID4VP, pure OIDC4IDA, or emerging decentralized routing protocols.
• Format Agnostic Evidence: The schema acts strictly as a standardized compliance and metadata "Cover Sheet". The underlying evidence MUST be transported in its native, unaltered cryptographic format (e.g., ISO 18013-5 Mobile Security Objects, W3C Verifiable Credentials in JSON-LD/BBS+, or SD-JWTs).

4. Normative Relying Party (RP) Processing Sequence

To ensure jurisdictional independence, prevent the acceptance of transcoded, unverified text, and strictly comply with the ISO 23220-4 Presentation Phase architecture, the Relying Party (acting as the mdoc Reader) MUST execute validation in the following sequential order.

The verification of the metadata envelope MUST NOT proceed until the native cryptographic proofs of the underlying payload are validated.

4.1 Trust Resolution (Verifier Identity Certificate Authority List)
Before evaluating a presentation, the mdoc Reader MUST establish local trust independent of the transport connection.
Action: The Reader resolves the public key material from a recognized Trust Anchor or Entity Configuration (e.g., an ISO-compliant VICAL). This caches the Issuing Authority Certificates (IACA) required for offline or zero-trust validation.

4.2 Device Engagement and Reader Authentication
During the initial presentation request, the mdoc Reader MUST assert its own identity and intent to the credential holder to mitigate cross-sector credential replay and establish a secure, authenticated channel.
Action: The Reader presents its cryptographic Reader Certificate (provisioned via the Trust Registry). The holder’s wallet validates this certificate against its local policies before releasing the identity evidence.

4.3 mdoc Authentication (Cryptographic Verification)
Upon receiving the presentation payload (e.g., via Device Retrieval or Network Retrieval), the mdoc Reader MUST execute the dual-verification process defined by ISO 18013-5 and ISO 23220-4 to validate the Mobile Security Object (MSO).
Issuer Authentication: The Reader isolates the embedded binary attachments and verifies the MSO’s digital signature against the cached IACA public keys (resolved in step 3.1). This mathematically proves the provenance of the data and ensures it has not been altered since issuance.

Device Authentication: The Reader verifies the cryptographic proof (e.g., a signature over the session transcript generated by the device's secure element) to ensure the mdoc is bound to the specific hardware presenting it. This provides the foundational defense against synthetic media and deepfake injections.

4.4 Data Extraction and Policy Correlation
Only after mdoc Authentication is mathematically proven successful may the mdoc Reader process the presentation for business logic.
Action: The Reader extracts the raw verifiable data (e.g., CBOR tags) and correlates it with the standardized plaintext metadata mapped in the overarching assurance schema (e.g., evaluating the assurance_classification and context_uri). The correlated, finalized payload is then committed to the verifier's internal audit log to satisfy the "Examiner Defense."

5. The Six Pillars: Jurisdictionally Independent Compliance/Risk Decision Elements

To enable global scalability, all jurisdictional parameters are abstracted using a standardized registry of Uniform Resource Names (URNs) and nested context definitions.

Pillar I: Provenance & Jurisdictional Assurance

• Requirement: Verify the credential was issued under recognized, government-mandated proofing standards (e.g., US NIST IAL2, EU eIDAS High, AU TDIF IP3, NZ DISTF High).
• Implementation: Utilize context_uri to define the governing legal framework and assurance_classification to assert the credential's compliance status within that specific framework.

Pillar II: Attribute Completeness (National Identifiers)

• Requirement: Verify jurisdictional tax, civic, or national identification numbers without requiring plaintext transmission or storage.
• Implementation: Implement a national_identifier_match object detailing the country context and identifier type (e.g., US TIN, EU PID, AU TFN, NZ IRD) to provide a generic, cryptographic boolean match signal.

Pillar III: Cryptographic Holder Binding (Binary Evidence)

• Requirement: Provide mathematical proof that the presenter is the legitimate owner of the credential and the authorized device.
• Implementation: Implementations MUST embed two distinct native attachments:
  1. Identity Provenance: The raw, unaltered credential (e.g., application/cbor for mDLs or application/vc+jwt for W3C VCs). Omitting this nullifies the Examiner Defense.
  2. Device Binding: The Hardware Key Attestation or dynamic Session Transcript (e.g. mode Reader Authentication or verifiable presentation signatures).

Pillar IV: Freshness & Revocation

• Requirement: Ensure the identity has not been revoked, suspended, or altered ("Reasonable Belief”).
• Implementation: Assert the check_method (e.g., a cryptographic Status List check or "revocation_freshness_check” from a wallet) and utilize standardized URNs for the organization serving as the authoritative registry for the authoritative status check.

Pillar V: Data Lineage & Auditability (The Examiner Defense)

• Requirement: Reconstruct the complete identity event for regulatory recordkeeping.
• Implementation: RPs satisfy strict auditability by persistently storing the complete, finalized payload (the metadata cover sheet and its embedded native binary attachments) entirely internally. This record MUST be indexed securely by the transaction session_id.

Pillar VI: Transaction Context & Consent

• Requirement: Bind the identity verification event to the specific operational intent (e.g., FinCEN CDD, GDPR purpose limitation, or CDR consent).
• Implementation: Inject account_intent and a verifiable consent_id directly into the verification object.

5.1 Security Consideration: Audience Binding (aud)

Because this profile acts independently of an OIDC network layer, standard token audience bindings (aud) are insufficient. The presentation envelope MUST establish cryptographic Verifier ...