Format-Agnostic Digital Identity Claims and Values: Identity Proofing Extension 1.0 - draft 00

3.1. The Identity Proofing Domain: Vetting & Assurance Claims

These claims are asserted by the Issuer and describe the rigor of the initial onboarding phase.¶

3.2. The Cryptographic Security & Presentation Domain

These claims establish the active trust architecture at the moment of presentation, providing an Examiner Defense against synthetic mimicry and proxy compromise.¶

4.1. Native Edge Binding (e.g., Proximity Terminals)

For RPs operating physical hardware (e.g., POS terminals, offline readers) consuming ISO/IEC 18013-5 over BLE/NFC, no format translation is required. The RP consumes the raw CBOR binary directly. The Core Vocabulary is parsed natively from the org.openid.ida.assurance.1 namespace.¶

4.2. Translation Binding (e.g., Web-Native OpenID Connect)

For web-native enterprise RPs (e.g., Core Banking Systems) that lack the capacity to process heavy binary protocols or manage edge device engagement, an intermediate Verifier is utilized. The Verifier executes the complex cryptography and translates the claims and values into a normalized JSON payload.¶

How the Verifier Uses This Table¶

When a Verifier sits between the Wallet and a Relying Party's enterprise backend, this IANA registry acts as the definitive translation map. If the Verifier receives a CBOR payload over ISO 18013-7, it doesn't look for the string "proofing_level". It parses the binary for the assigned integer key (e.g., -260). Upon validating the math, it cross-references this IANA registry, sees that -260 perfectly maps to the JWT claim "proofing_level", and injects that string into the normalized OpenID Connect JSON envelope for the Relying Party. This ensures complete semantic parity between the physical edge and the enterprise web.¶

• Encoding Mandate: When utilizing a JSON translation binding, all non-JSON cryptographic structures (e.g., CBOR MSO blocks) mapped to issuer_signed_receipt and device_signed_receipt MUST be encoded (e.g., Base64URL) to allow safe nesting within the JSON envelope.¶

5.1. The Envelope vs. The Receipt (Format Translation Integrity)

If a Relying Party utilizes an intermediate Verifier and a Translation Binding (such as OIDC JSON), the RP relies on the JSON envelope to execute immediate, automated business logic. However, the JSON envelope alone is legally insufficient for Examiner Defense, as it could be synthesized by a compromised Verifier.¶

The RP MUST NOT treat the JSON translation as the absolute root of trust. The RP MUST extract and archive the format-agnostic cryptographic evidence contained within the issuer_signed_receipt and device_signed_receipt fields. While the RP consumes JSON for operational speed, the retained encoded binary receipts provide the immutable proof required for KYC Examiner Defence.¶

5.2. Decoupled Trust Resolution (Asynchronous Caching)

To eliminate runtime network latency and protect user privacy, architectures processing these claims SHOULD decouple the transaction path from the trust list resolution path. Synchronous API calls to a Verified Issuer Certificate Authority List (VICAL) during a live transaction introduces severe availability risks. revocation_freshness_method MUST be evaluated by the RP to determine if the trust resolution was performed via an asynchronous, locally cached registry, a synchronous network call or the wallet itself.¶

6.1. Namespace Enforcement

Establish a standardized, format-agnostic namespace (e.g., org.openid.ida.assurance.1) that Issuers MUST incorporate natively into the credential to explicitly declare the proofing standards met.¶

6.2. Selective Disclosure Request

RPs SHOULD explicitly request proofing data elements from this namespace via Selective Disclosure during the presentation phase to evaluate the native assurance level of the Issuer's vetting process prior to full PII payload presentation and extraction.¶

7.1. JSON Web Token Claims Registration

This specification requests registration of the following value in the IANA "JSON Web Token Claims Registry" established by [RFC7519]. These registrations standardize the semantic representation of how an identity was vetted and proofed prior to issuance, allowing Relying Parties to evaluate identity proofing rigor across format-agnostic architectures.¶

Registry Name: JSON Web Token Claims Change Controller: OpenID Foundation Specification Document: [[ This Document ]]¶

7.2. CBOR Web Token (CWT) Claims Registration

This specification requests registration of the following value in the IANA "CBOR Web Token Claims Registry" established by [RFC8392]. These registrations provide integer-based claim keys for the Format-Agnostic Identity Core Vocabulary, enabling high-assurance identity proofing and cryptographic pass-through evidence to be transmitted efficiently in edge-native constrained environments.¶

Registry Name: CBOR Web Token (CWT) Claims Change Controller: OpenID Foundation (or IETF, depending on the final submission track) Specification Document: [[ This Document ]]¶

Note to RFC Editor: Please replace [TBD] with the integer values assigned by IANA, typically allocated from the standard specification space (e.g., negative integers for early allocations or standard positive integers post-RFC).¶