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

	Format-Agnostic Identity Claims and Valu	September 2026
Cafik	Standards Track	[Page]

Abstract

This specification is an extension of OpenID Connect for Identity Assurance Claims Registration 1.0. It defines discrete claims and values describing Identity Proofing assurance (the vetting and issuance process performed by an issuer or identity provider). By standardizing the semantic representation of these claims, this profile provides Relying Parties (RPs) with critical assurance information that enables automated risk decisions when accepting an identity credential or assertion. Considerations for evaluating the cryptographic evidence and trust architecture associated with a given presentation are addressed in Security Considerations and are left to the implementation architectures rather than defined here as normative claims.¶

3. Standardized Claims and Values Registry (Normative)

To enable true jurisdictional agility and non-repudiation, Issuers and Verifiers MUST map local proofing terminology and downstream translation assertions to this standardized registry of claims and enumerated values. This registry is strictly divided into two operational domains: Identity Proofing and Cryptographic Security.¶

Identity Proofing claim names and values in this specification are aligned with OpenID Identity Assurance Schema Definition 1.0 and the eKYC-IDA predefined values.¶

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.1.1. Context & Environmental Claims

Table 1
Claim	Example Parameter Values	Data Type	Description
`trust framework`	`eidas` `Nist_800_63Aus_real_id` String	Trust Framework that governed identity proofing act issuance. This value determines how `assurance_level` is interpreted.

3.1.2. Assurance Levels

assurance_level is interpreted only in combination with trust_framework. This specification does not define a framework-independent "harmonized IAL" string. Framework and level MUST NOT be concatenated into a single compound token (for example loa:high:eu:eidas).¶

Optional evidence-classification detail, when required by a framework, is carried in IDA assurance_process and is out of scope for this specification.¶

Table 2
Claim	Example Parameter Values	Data Type	Description
`assurance_level`	`high` `substantial` `ial2` String	Assurance level associated with the proofed identity, as defined by the identified `trust_framework`.
`proofing_level`	`ial:2`, `ip:3`	String	Harmonized mapping representing the Identity Assurance Level (IAL).

3.1.3. Proofing Verification Methods (`check_method`)

The values in the table below are conveyed via the check_method claim registered in the IANA JWT and CWT tables later in this document. Presence of the subject during proofing is determined by check_method and SHALL NOT be separately asserted.¶

Table 3
Claim	Value	Description
`check_method`	`pipp`	Physical In-Person Proofing
`check_method`	`uripp`	Unsupervised Remote In-Person Proofing
`check_method`	`sripp`	Supervised Remote In-Person Proofing

3.1.4. Assurance Namespace

To enable cross-format interoperability of proofing claims, implementations MUST utilize a registered OpenID IDA Assurance namespace: * ISO/IEC 18013-5/7 (CBOR mdoc): org.openid.ida.assurance.1 * W3C Verifiable Credentials (JSON/SD-JWT): assurance_level property mapped within the credential @context.¶

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.¶

3.2.1. Live Presentation Metrics

Table 4
Claim	Data Type	Description
`revocation_freshness_check`	String (RFC 3339 DateTime)	Timestamp confirming the exact moment the credential's status was validated. Must use YYYY-MM-DDThh:mm:ssTZD per RFC 3339 (a profile of ISO 8601) with a required timezone designator, consistent with IDA's verification.time - not an RFC 7519 NumericDate (which applies to exp/iat).
`revocation_freshness_method`	String	Mechanism used to validate status (e.g., `cached_vical`, `status_list`, `ocsp`, `token_status_api`), determining the risk of cache poisoning.
`device_binding_verified`	Boolean	Declares whether the presentation key is bound securely to physical hardware (`TRUE`/`FALSE`).

4. Architectural Binding Profiles (Implementation Mechanics)

Because this specification is protocol-independent, Relying Parties MUST consume these claims via an architecture-appropriate Implementation Profile.¶

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. Security Considerations

While this specification defines claims meant to provide Relying Parties with assurance information about a given credential or assertion, it does not define the architecture, trust model, or cryptographic properties needed to verify the assurance of the claims themselves. Depending on the use case and trust architecture, Relying Parties need to determine the credential types and cryptographic validity and integrity protections needed to accept a given credential or assertion. This section provides security considerations for relying parties when evaluating and accepting the claims defined in this specification. The security considerations outlined assume that claims are provided to a relying party either as attributes in an identity credential, such as a verifiable digital credential, or as part of an identity assertion, such as an Open ID Connect token. The security controls chosen will be greatly impacted by relying party risk tolerance and the architecture between the issuer/identity provider, the verifier and the relying party. For example, some relying parties may require the credential or assertion to be signed by the issuer/identity provider, while others may rely only on an encrypted channel for trust conveyance.¶

Where cryptographic evidence is used to support a risk-based decision, its conveyance, retention, and format are implementation-specific and are left to the applicable architecture and trust framework rather than defined as normative claims in this document. This section does highlight examples of how normative claims currently in the IDA specification can be used to express the security properties of how an assertion or credential was cryptographically protected during transport and verified.¶

5.1. Certification

This section will talk about security considerations agnostic of IdP, Issuer, Wallet or Verifier certification. However, it’s worth noting that current and evolving third-party certification regimes for identity infrastructure may impact the claims relying parties choose to accept. For example, a single claim that attests to an issuer’s identity proofing process being certified against accepted requirements may replace the need for several, granular claims about the mechanism and controls used in the proofing process. Relying parties should evaluate availability and applicability of certification when assessing the risk of accepting identity and assurance claims.¶

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

When a Relying Party utilises an intermediate Verifier and a Translation Binding (such as OIDC JSON), the RP typically relies on the JSON envelope for immediate business logic. The JSON envelope alone is insufficient for Examiner Defence: it could be synthesised by a compromised or malicious Verifier.¶

The RP shall not treat the translated JSON envelope as the sole root of trust.
The RP shall extract and archive the format-agnostic cryptographic evidence contained in the issuer_signed_receipt and device_signed_receipt fields (and, when present, verifier_signature_attestation).¶

While the RP may consume the JSON translation for operational speed, the retained encoded binary (or equivalent) receipts constitute the immutable evidence required for non-repudiation and KYC Examiner Defence. This requirement applies equally to native edge presentations, pure VCDM flows, and translated OIDC flows.¶

5.3. 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 / VICAL resolution path. Synchronous API calls to a Verified Issuer Certificate Authority List (VICAL) or equivalent during a live transaction introduce availability and privacy risks.¶

The RP shall evaluate the revocation_freshness_method claim (when present) to determine whether status validation was performed via:¶

an asynchronous, locally cached registry,¶
a synchronous network call, or¶
the wallet / device itself.¶

This evaluation is a necessary input to the RP’s residual-risk assessment.¶

5.4. Independence from End-User Attribute Claims

The security requirements in this section apply to the cryptographic evidence and presentation-integrity claims defined in this specification. They are independent of whether any end-user attribute claims registered in OpenID Connect for Identity Assurance Claims Registration 1.0 are also present in the assertion.¶

5.5. Decoupled Trust Resolution (Asynchronous Caching)

The RP shall evaluate the revocation_freshness_method claim (when present) to determine whether status validation was performed via:¶

an asynchronous, locally cached registry,¶
a synchronous network call, or¶
the wallet / device itself.¶

This evaluation is a necessary input to the RP’s residual-risk assessment.# Compliance Elements: Provenance & Jurisdictional Assurance¶

5.6. 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.¶

5.7. 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.¶

6. IANA Considerations

6.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 ]]¶

Table 5
Claim Name	Claim Description	Change Controller	Specification Document(s)
`context_uri`	Defines the legal or regulatory standard governing the initial identity proofing.	OpenID Foundation	[[ This Document ]]
`presence_equivalence`	Indicates the context of the user's presence during the initial proofing phase.	OpenID Foundation	[[ This Document ]]
`issuance_assurance_classification`	Asserts the vetting rigor and confidence established by the Issuer at the time of issuance.	OpenID Foundation	[[ This Document ]]
`proofing_level`	Harmonized mapping representing the Identity Assurance Level (IAL) or Identity Proofing (IP) level.	OpenID Foundation	[[ This Document ]]
`check_method`	The verification methodology used by the Issuer to validate the identity evidence during onboarding.	OpenID Foundation	[[ This Document ]]

6.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 ]]¶

Table 6
Claim Name	Claim Description	JWT Claim Name	Claim Key
`context_uri`	Defines the legal/regulatory standard governing the initial proofing.	`context_uri`	`[TBD]`
`presence_equivalence`	Indicates the context of the user's presence during proofing.	`presence_equivalence`	`[TBD]`
`issuance_assurance_classification`	Asserts the vetting rigor and confidence established by the Issuer.	`issuance_assurance_classification`	`[TBD]`
`proofing_level`	Harmonized mapping representing the Identity Assurance Level.	`proofing_level`	`[TBD]`
`check_method`	The verification methodology used during onboarding.	`check_method`	`[TBD]`
`revocation_freshness_check`	Timestamp confirming the exact moment the credential's status was validated.	`revocation_freshness_check`	`[TBD]`
`revocation_freshness_method`	Mechanism used to validate the credential's status.	`revocation_freshness_method`	`[TBD]`
`device_binding_verified`	Declares whether the presentation key is securely bound to hardware.	`device_binding_verified`	`[TBD]`

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).¶

Appendix A. Notices

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶

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