From 4d55a8d645791dd793c1e90c8689ac8b38d8ca75 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 15:04:10 +0200 Subject: [PATCH 01/16] bumps versions of OID4VCI and OID4VP to 1.0, bumps SD-JWT VC from draft 08 to draft 13 and IETF Token Status List from draft 10 to draft 13 --- spec/spec.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/spec/spec.md b/spec/spec.md index 0382a19..7a2e94b 100644 --- a/spec/spec.md +++ b/spec/spec.md @@ -31,13 +31,13 @@ The Decentralized Identity Interop Profile, or DIIP for short, defines requireme | Purpose | Specification | | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | -| Credential format | [[ref: W3C VCDM]] 2.0 (20 March 2025) and [[ref: SD-JWT VC]] (draft 08) | -| Signature scheme | SD-JWT as specified in [[ref: VC-JOSE-COSE]] (20 March 2025) and [[ref: SD-JWT VC]] (draft 08) | +| Credential format | [[ref: W3C VCDM]] 2.0 (20 March 2025) and [[ref: SD-JWT VC]] (draft 13) | +| Signature scheme | SD-JWT as specified in [[ref: VC-JOSE-COSE]] (20 March 2025) and [[ref: SD-JWT VC]] (draft 13) | | Signature algorithm | [[ref: ES256]] (RFC 7518 May 2015) | -| Identifying [[ref: Issuer]]s, [[ref: Holder]]s, and [[ref: Verifier]]s | [[ref: did:jwk]] (Commit 8137ac4, Apr 14 2022) and [[ref: did:web]] (31 July 2024) | -| Issuance protocol | OpenID for Verifiable Credentials Issuance ([[ref: OID4VCI]]) (Draft 15) | -| Presentation protocol | OpenID for Verifiable Presentations ([[ref: OID4VP]]) (Draft 28) | -| Revocation mechanism | [[ref: IETF Token Status List]] (Draft 10, 2025-04-16) | +| Identifying [[ref: Issuer]]s, [[ref: Holder]]s, and [[ref: Verifier]]s | [[ref: did:jwk]] (Commit 8137ac4, Apr 14 2022) and [[ref: did:web]] (31 July 2024) | +| Issuance protocol | OpenID for Verifiable Credentials Issuance ([[ref: OID4VCI]]) (1.0). | +| Presentation protocol | OpenID for Verifiable Presentations ([[ref: OID4VP]]) (1.0) | +| Revocation mechanism | [[ref: IETF Token Status List]] (Draft 13, 2025-11-11) | The [Normative References](#normative-references) section links to the versions of specifications that DIIP-compliant implementations must support. @@ -287,13 +287,13 @@ This section consolidates in one place common terms used across open standards t ~ `ECDSA` using `P-256` ([[ref: Secp256r1]]) and `SHA-256` as specified in [RFC 7518 JSON Web Algorithms (JWA)](https://datatracker.ietf.org/doc/html/rfc7518). Status: RFC - Proposed Standard. [[def: IETF Token Status List]] -~ [Token Status List - draft 10](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/10/). Status: Internet-Draft. +~ [Token Status List - draft 13](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/13/). Status: Internet-Draft. [[def: OID4VCI]] -~ [OpenID for Verifiable Credential Issuance - draft 15](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID2.html). Status: Second Implementer's Draft. +~ [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). Status: Second Implementer's Draft. [[def: OID4VP]] -~ [OpenID for Verifiable Presentations - draft 28](https://openid.net/specs/openid-4-verifiable-presentations-1_0-28.html). Status: Third Implementer's Draft. +~ [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html). Status: Third Implementer's Draft. [[def: PAR]] ~ [RFC 9126 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126). Status: RFC - Proposed Standard. @@ -302,7 +302,7 @@ This section consolidates in one place common terms used across open standards t ~ [RFC 7636 Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636). Status: RFC - Proposed Standard. [[def: SD-JWT VC]] -~ [SD-JWT-based Verifiable Credentials (SD-JWT VC) - draft 08](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/08/). Status: WG Document. +~ [SD-JWT-based Verifiable Credentials (SD-JWT VC) - draft 13](hhttps://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/13/). Status: WG Document. [[def: Secp256r1]] ~ `Secp256r1` curve in [RFC 5480 ECC SubjectPublicKeyInfo Format](https://datatracker.ietf.org/doc/html/rfc5480). Status: RFC - Proposed Standard. From 06594fd29e1bd09df4a3d13a7a8211a88d7c0701 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 15:13:51 +0200 Subject: [PATCH 02/16] formatting changes based on markdown-lint --- spec/spec.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/spec/spec.md b/spec/spec.md index 7a2e94b..f605685 100644 --- a/spec/spec.md +++ b/spec/spec.md @@ -1,5 +1,4 @@ -Decentralized Identity Interop Profile v5-draft -================== +# Decentralized Identity Interop Profile v5-draft **Profile Status:** Draft @@ -41,7 +40,7 @@ The Decentralized Identity Interop Profile, or DIIP for short, defines requireme The [Normative References](#normative-references) section links to the versions of specifications that DIIP-compliant implementations must support. -This document is not a specification but a **profile**. It outlines existing specifications required for implementations to interoperate with each other. +This document is not a specification but a **profile**. It outlines existing specifications required for implementations to interoperate with each other. It also clarifies mandatory features for the options mentioned in the referenced specifications. The main objective of this profile is to allow for easy adoption and use the minimum amount of functionality for a working [[ref: Digital Credential]] ecosystem. @@ -54,9 +53,10 @@ The latest published DIIP profile can be found at [https://FIDEScommunity.github ### Audience -The audience of this document includes organisations aiming to issue or verify [[ref: Digital Credential]]s, as well as the implementers of [[ref: Digital Credential]] solutions ([[ref: Wallet]]s and [[ref: Agent]]s). +The audience of this document includes organisations aiming to issue or verify [[ref: Digital Credential]]s, as well as the implementers of [[ref: Digital Credential]] solutions ([[ref: Wallet]]s and [[ref: Agent]]s). ### Development of the DIIP Profile + Participate: ~ [GitHub repo](https://github.com/FIDEScommunity/DIIP.git) ~ [File a bug](https://github.com/FIDEScommunity/DIIP/issues) @@ -84,7 +84,7 @@ The [Terminology](#terminology) section explains the key terms used in this prof ## Goals -The [[ref: W3C VCDM]] specification defines a data model for [[ref: Digital Credential]]s but does not prescribe standards for transport protocol, key management, authentication, query language, etc. +The [[ref: W3C VCDM]] specification defines a data model for [[ref: Digital Credential]]s but does not prescribe standards for transport protocol, key management, authentication, query language, etc. The ([[ref: OID4VCI]]) and ([[ref: OID4VP]]) protocols define the interaction between [[ref: Wallet]]s and [[ref: Agent]]s but don't specify a data model or a credential format. @@ -104,20 +104,21 @@ In the context of the European eIDAS regulation ([[ref: eIDAS]]) and its Archite [[ref: Wallet]]s and [[ref: Agent]]s may support both DIIP and the OpenID4VC High Assurance Interoperability Profile ([[ref: HAIP]]). [[ref: HAIP]] is targeted for high-assurance use cases where it is important to bind the credentials to the [[ref: Holder]]'s private key (device binding). DIIP is the profile for other use cases. -The standards used in the DIIP profile are the same ones that the [[ref: ARF]] uses, but DIIP makes different choices to [[ref: HAIP]] in some areas where [[ref: OID4VCI]] and [[ref: OID4VP]] provide optionality. +The standards used in the DIIP profile are the same ones that the [[ref: ARF]] uses, but DIIP makes different choices to [[ref: HAIP]] in some areas where [[ref: OID4VCI]] and [[ref: OID4VP]] provide optionality. While DIIP is a standalone profile and enables interoperability on it's own, it is designed to build upon and integrate with the EUDI wallet. Therefore, DIIP implementers who want to integrate with the EUDI Wallet should support [[ref: HAIP]] and the implementation regulations issued by the European Commission. ## Profile + In this section, we describe the interoperability profile. ### Credential Format + The W3C Verifiable Credential Data Model ([[ref: W3C VCDM]]) defines structure and vocabulary well suited for [[ref: Digital Credential]]s in DIIP's scope. For example, the [[ref: Open Badges 3]] credentials use [[ref: W3C VCDM]] as the data format. The SD-JWT-based Verifiable Credentials specification ([[ref: SD-JWT VC]]) defines a credential format that are serialized in JSON Web Tokens ([[ref: JWT]]s) and enable selective disclosure. [[ref: SD-JWT VC]] is used as a credential format for person identification data (PID) in [[ref: HAIP]] and [[ref: ARF]] (in addition to `mDocs`). -[[ref: W3C VCDM]] recommends securing Verifiable Credentials using JOSE and COSE ([[ref: VC-JOSE-COSE]]) as an *enveloping proof* mechanism and -Verifiable Credential Data Integrity 1.0 ([[ref: VC-DATA-INTEGRITY]]) as an *embedded proof* mechanism. +[[ref: W3C VCDM]] recommends securing Verifiable Credentials using JOSE and COSE ([[ref: VC-JOSE-COSE]]) as an *enveloping proof* mechanism and Verifiable Credential Data Integrity 1.0 ([[ref: VC-DATA-INTEGRITY]]) as an *embedded proof* mechanism. To keep things as simple as possible, DIIP requires implementations to use `SD-JWT` as the mechanism to secure also [[ref: W3C VCDM]]-based credentials. @@ -132,19 +133,23 @@ The DIIP profile chooses one key type [[ref: Secp256r1]] and one signature metho **Requirement: DIIP-compliant implementations MUST support [[ref: ES256]] (`ECDSA` using [[ref: Secp256r1]] curve and `SHA-256` message digest algorithm).** ### Identifiers + DIIP prefers decentralized identifiers ([[ref: DID]]s) as identifiers. An entity identified by a [[ref: DID]] publishes a [DID Document](https://www.w3.org/TR/did-1.0/#dfn-did-documents), which can contain useful metadata about the entity, e.g., various endpoints. There are many DID methods defined. The DIIP profile requires support for two of them: [[ref: did:jwk]] and [[ref: did:web]]. In many use cases, organizations are identified by [[ref: did:web]], and the natural persons are identified by [[ref: did:jwk]]. **Requirement: DIIP-compliant implementations MUST support [[ref: did:jwk]] and [[ref: did:web]] as the identifiers of the [[ref: Issuer]]s, [[ref: Holder]]s, and [[ref: Verifier]]s.** ### Trust Establishment + Signatures in [[ref: Digital Credential]]s can be used to verify that the content of a credential has not been tampered with. But anyone can sign a credential and put anything in the issuer field. [[ref: Digital Credential]] ecosystems require that there is a way for a [[ref: Verifier]] to check who is the [[ref: Issuer]] of a [[ref: Digital Credential]]. Equally, a user might want to be informed about the trustworthiness of a [[ref: Verifier]] before choosing to share credentials. The DIIP v4 profile doesn't require compliant implementations to support any trust establishment mechanism. ### Issuance + The issuance of [[ref: Digital Credential]]s from the [[ref: Issuer]] to the [[ref: Holder]]'s [[ref: Wallet]] is done along the [[ref: OID4VCI]] specification. Other protocols exist, but [[ref: OID4VCI]] is very broadly supported and also required by [[ref: HAIP]]. #### OID4VCI + OpenID for Verifiable Credential Issuance ([[ref: OID4VCI]]) defines an API for the issuance of [[ref: Digital Credential]]s. OID4VCI [issuance flow variations](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID2.html#name-issuance-flow-variations) leave room for optionality. @@ -193,9 +198,11 @@ The `scope` parameter is a light-weight way of using an external authorization s **Requirement: DIIP-compliant implementations MUST support a `cnf` holder binding claim in the [[ref: Issuer]]'s `jwt` and it MUST include a `kid` value from the `authentication` Verification Method relationship of the respective [[ref: Holder]]'s [[ref: DID]] document.** ### Presentation + The presentation of claims from the [[ref: Holder]]'s [[ref: Wallet]] to the [[ref: Verifier]] is done along the [[ref: OID4VP]]. Other protocols exist, but [[ref: OID4VP]] is very broadly supported and also required by [[ref: HAIP]]. #### OID4VP + Using [[ref: OID4VP]], the [[ref: Holder]]s can also present cryptographically verifiable claims issued by third-party [[ref: Issuer]]s, such that the [[ref: Verifier]] can place trust in those [[ref: Issuer]]s instead of the subject ([[ref: Holder]]). [[ref: OID4VP]] supports scenarios where the *Authorization Request* is sent both when the [[ref: Verifier]] is interacting with the [[ref: Holder]] using the device that is the same or different from the device on which requested [[ref: Digital Credential]]s are stored. @@ -203,6 +210,7 @@ Using [[ref: OID4VP]], the [[ref: Holder]]s can also present cryptographically v **Requirement: DIIP-compliant implementations MUST support both *Same-device Flow* and *Cross-device Flow*.** According to [[ref: OID4VP]], the [[ref: Verifier]] may send an *Authorization Request* using either of these 3 options: + - Passing as URL with encoded parameters - Passing a request object as value - Passing a request object by reference @@ -219,6 +227,7 @@ DIIP only requires support for the last option. **Requirement: DIIP-compliant implementations MUST support the `did` *Client Identifier Scheme*.** The following features of [[ref: OID4VP]] are **not** required by this version of the DIIP profile: + - Presentations Without Holder Binding Proofs (section 5.3, requirements for the `state` parameter) - Verifier Attestations (section 5.11) - SIOPv2 (section 8, *Response Type* value `vp_token id_token` and `scope` containing `openid`) @@ -227,6 +236,7 @@ The following features of [[ref: OID4VP]] are **not** required by this version o - Digital Credentials API (Appendix A) ### Validity and Revocation Algorithm + Expiration algorithms using [validFrom](https://www.w3.org/TR/vc-data-model-2.0/#defn-validFrom) and [validUntil](https://www.w3.org/TR/vc-data-model-2.0/#defn-validUntil) are a powerful mechanism to establish the validity of credentials. Evaluating the expiration of a credential is much more efficient than using revocation mechanisms. While the absence of `validFrom` and `validUntil` would suggest a credential is considered valid indefinitely, it is recommended that all implementations set validity expiration whenever possible to allow for clear communication to [[ref: Holder]]s and [[ref: Verifier]]s. **Requirement: DIIP-compliant implementations MUST support checking the validity status of a [[ref: Digital Credential]] using `validFrom` and `validUntil` when they are specified.** @@ -241,7 +251,6 @@ The [[ref: Bitstring Status List]] is based on the same idea as the [[ref: IETF This section consolidates in one place common terms used across open standards that this profile consists of. For the details of these, as well as other useful terms, see the text within each of the specifications listed in [References](#references). - [[def: Agent]] ~ A software application or component that an [[ref: Issuer]] uses to issue [[ref: Digital Credential]]s or that a [[ref: Verifier]] uses to request and verify them. @@ -271,7 +280,7 @@ This section consolidates in one place common terms used across open standards t ~ An entity that requests and receives one or more [[ref: Digital Credential]]s for processing. [[def: Wallet]] -~ A software application or component that receives, stores, presents, and manages credentials and key material of an entity. +~ A software application or component that receives, stores, presents, and manages credentials and key material of an entity. ## References From 84a26e1868ed509d2b8e6f2c249400804f601510 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 16:14:57 +0200 Subject: [PATCH 03/16] bumped version --- package-lock.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package-lock.json b/package-lock.json index 05e8665..25708ae 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "decentralized-identity-interop-profile", - "version": "4.0.0", + "version": "5.0.0-draft1", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "decentralized-identity-interop-profile", - "version": "4.0.0", + "version": "5.0.0-draft1", "license": "Apache 2.0", "dependencies": { "spec-up": "^0.10.8" From 4516ec6822e2fb704341ce2d26bc5115f7cf54bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 16:15:31 +0200 Subject: [PATCH 04/16] added federation profile --- spec/federation-profile.md | 248 +++++++++++++++++++++++++++++++++++++ specs.json | 3 +- 2 files changed, 250 insertions(+), 1 deletion(-) create mode 100644 spec/federation-profile.md diff --git a/spec/federation-profile.md b/spec/federation-profile.md new file mode 100644 index 0000000..8464bd3 --- /dev/null +++ b/spec/federation-profile.md @@ -0,0 +1,248 @@ +## Appendix B: OpenID Federation Digital Credentials Profile + +### Introduction + +This specification profiles OpenID Federation [[ref: OpenID Federation]] for use with digital credentials, specifically focusing on credential issuance via OpenID for Verifiable Credential Issuance [[ref: OID4VCI]] and credential presentation via OpenID for Verifiable Presentations [[ref: OID4VP]]. + +The profile simplifies federation usage by limiting scope to trust chain resolution and metadata discovery, while omitting more complex features such as federation policies and trust marks. + +#### Scope + +This profile applies to: + +- Credential issuers publishing OID4VCI metadata +- Credential verifiers publishing verifier metadata +- Wallets resolving trust chains to establish trust in issuers and verifiers + +This profile does not apply to and does not require conforming implementations to support: + +- Chapter 6 (Federation Policy) of OpenID Federation +- Chapter 7 (Trust Marks) of OpenID Federation +- Chapter 12 (OpenID Connect Client Registration) of OpenID Federation + +### Terminology + +This specification uses the terms defined in OpenID Federation [[ref: OpenID Federation]], OpenID for Verifiable Credential Issuance [[ref: OID4VCI]], OpenID for Verifiable Presentations [[ref: OID4VP]], and SD-JWT VC [[ref: SD-JWT VC]]. + +**Entity Identifier**: As defined in OpenID Federation, a URL that uniquely identifies a federation entity. + +**Entity Configuration**: As defined in OpenID Federation, a signed JWT published at the Entity Identifier's `/.well-known/openid-federation` endpoint containing metadata and authority hints. + +**Trust Chain**: As defined in OpenID Federation, a sequence of Entity Statements from a Leaf Entity through intermediate entities to a Trust Anchor. + +**Issuer**: The role of the entity issuing credentials as defined in [[ref: W3C VCDM]] + +**Credential Issuer**: The technical service used to issue credentials as defined in [[ref: OID4VCI]] + +**Verifier**: The entity that requests, receives, and validates Presentations as defined in [[ref: OID4VCI]]. Note that this specification does not distinguish the role and the technical service of the verifier the same way it does for Issuer and Credential Issuer. For the purposes of this specification Verifier may refer to either the role or the technical service. (Thus, the reference to the definition in [[ref: OID4VCI]] and not the one in [[ref: OID4VP]].) + +### Credential Issuance + +#### Entity Identifier + +The Credential Issuer MUST use the value of the `credential_issuer` in its OID4VCI issuer metadata as its Entity Identifier. + +The Credential Issuer's Entity Configuration can be found by appending the string `/.well-known/openid-federation` to the Entity Identifier. + +#### Issuer Metadata Publication + +The Credential Issuer MUST place the OpenID4VCI issuer metadata into the Entity Configuration, in the `openid_credential_issuer` property. + +If the `openid_credential_issuer` property is found in the Entity Configuration, the Wallet MUST use only it and ignore the issuer metadata published in the well-known location defined in OID4VCI. + +The Credential Issuer MAY place additional metadata into the `federation_entity` Entity Type Identifier. + +The metadata in the `openid_credential_issuer` property overrides the metadata in the `federation_entity` property. For example, if both `openid_credential_issuer.display.name` and `federation_entity.organization_name` exist, the Wallet SHOULD show the value of `openid_credential_issuer.display.name` as the name of the issuer. + +#### Example: Credential Issuer Entity Configuration + +```json +{ + "iss": "https://credential-issuer.example", + "sub": "https://credential-issuer.example", + "iat": 1616239022, + "exp": 1616239322, + "metadata": { + "federation_entity": { + "organization_name": "Example Credential Issuer", + "contacts": ["support@credential-issuer.example"] + }, + "openid_credential_issuer": { + "issuer": "https://credential-issuer.example", + "display": [ + { + "name": "Example Issuer", + "locale": "en-US", + "logo": { + "uri": "https://credential-issuer.example/logo.png", + "alt_text": "Example Logo" + } + } + ], + "credential_issuer": "https://credential-issuer.example", + "authorization_endpoint": "https://credential-issuer.example/authorize", + "authorization_servers": ["https://credential-issuer.example/authorize"], + "credential_endpoint": "https://credential-issuer.example/credential", + "credential_configurations_supported": { + "sd_jwt_vc_example": "..." + } + }, + "openid-configuration": { + "jwks_uri": "https://credential-issuer.example/jwks" + } + }, + "jwks": [ + { + "kty": "EC", + "kid": "MJ2BW-rNshp9sjh3SvwnBIkEsYsU92xVtC3-Fv_lcKc", + "alg": "ES256", + "crv": "P-256", + "x": "JTEE5QghmkA_-7_pZoKIluRzGNvQGtzmpNvb_nAswhE", + "y": "A_iBfIseHsdfE7CmI3lIYtKMdfyXXOIpPX_o6O0h0wY", + "use": "sig" + } + ], + "authority_hints": [ + "https://trustregistry.example" + ] +} +``` + +#### SD-JWT VC Credentials + +When the [[ref: Issuer]] issues credentials in the [[ref: SD-JWT VC]] format, the Issuer MUST place its Entity Identifier in the `fed` claim of the credential. + +##### Example: SD-JWT VC with Federation Claim + +The following non-normative example shows a decoded payload of an [[ref: SD-JWT VC]] credential with the `fed` claim: + +```json +{ + "iss": "https://credential-issuer.example", + "fed": "https://credential-issuer.example", + "iat": 1683000000, + "exp": 1883000000, + "vct": "https://credentials.example.com/identity_credential", + "is_over_65": true, + "address": { + "street_address": "123 Main St", + "locality": "Anytown", + "region": "Anystate", + "country": "US" + } +} +``` + +#### W3C VCDM Credentials + +When the [[ref: Issuer]] issues credentials in the [[ref: W3C VCDM]] format, the Issuer MUST place a `termsOfUse` property into the credential. The `type` of this `termsOfUse` property MUST be the string `OpenIDFederation` and the `policyId` MUST be the Issuer's Entity Identifier. + +##### Example: W3C VCDM Credential with termsOfUse + +The following non-normative example illustrates the use of the `termsOfUse` property: + +```json +{ + "@context": [ + "https://www.w3.org/ns/credentials/v2" + ], + "id": "urn:uuid:c65d364e-2560-4e08-be03-9c3d944d609d", + "type": [ + "VerifiableCredential" + ], + "issuer": "did:web:credential-issuer.example", + "validFrom": "2025-12-01T00:00:00Z", + "validUntil": "2028-12-31T23:59:59Z", + "credentialSubject": { + }, + "termsOfUse": { + "type": "OpenIDFederation", + "trustFramework": "Example Federation", + "policyId": "https://credential-issuer.example" + } +} +``` + +#### Note on Credential Issuer vs. Issuer + +The Issuer defined in the digital credential (the value of the `iss` claim in SD-JWT VC credentials or the value of the `id` of the `issuer` property in W3C VCDM credentials) is not necessarily the same entity as the Credential Issuer defined in the property `credential_issuer` in the OID4VCI metadata. + +For example, the OpenID Federation Entity Identifier of the Issuer of the credential could be `https://university-of-utopia.example.edu` and the OpenID Federation Entity Identifier of the Credential Issuer could be `https://credentials.ministryofeducation.example.edu`. + +If the Issuer chooses to make this kind of distinction between the entity issuing the credential and the technical service used for issuance, it is RECOMMENDED that the Entity Configuration of the technical service has an `authority_hints` value pointing to the Issuer's Entity Identifier and the Issuer publishes a Subordinate Statement about the technical service. + +### Credential Presentation and Verification + +#### Client Identifier Scheme + +The Verifier MUST use the `openid_federation:` prefix as defined in [[ref: OID4VP]] Section 5.9.3. + +#### Verifier Metadata Publication + +The Verifier MUST place verifier metadata into the Entity Configuration, in the `openid_credential_verifier` property. + +### Trust Establishment + +To establish trust with the issuer (ensure that the issuer can be trusted), the Verifier MUST resolve the Trust Chain from the issuer's Entity Configuration until it finds a Federation Entity it trusts. + +#### Example: Verifier Entity Configuration + +```json +{ + "iss": "https://credential-verifier.example", + "sub": "https://credential-verifier.example", + "iat": 1616239023, + "exp": 1616239323, + "metadata": { + "federation_entity": { + "organization_name": "Example Credential Verifier", + "contacts": ["support@credential-verifier.example"] + }, + "openid_credential_verifier": { + "jwks": { + "keys": [ + { + "kty": "EC", + "crv": "P-256", + "x": "f83OJ3D2xF4Z1s3QpLQe4qVb8K7q6y1v3z4Yb6k9J0", + "y": "x_FEzRu9q3u4bWz5n9X2L4q1U8T7c6v5s2d1a0b3C4", + "alg": "ES256", + "use": "enc", + "kid": "ec-key-1" + } + ] + }, + "encrypted_response_enc_values_supported": [ + "A128GCM", + "A192GCM", + "A256GCM" + ], + "vp_formats_supported": { + "dc+sd-jwt": { + "sd-jwt_alg_values": ["ES256"], + "kb-jwt_alg_values": ["ES256"] + } + } + } + }, + "jwks": [ + { + "kty": "EC", + "kid": "y4nC8uTvcM5uJxOIvUqFjXb2EA6xPGdnt8zvjW94m6U", + "alg": "ES256", + "crv": "P-256", + "x": "K6dA9ayt4P8xBN6SFiCZYOI2qeaFda7VV5wnmHWcl7w", + "y": "CdE30dUX0geK4NL8IMC9u-rRMOLC9WaScJIGK5rxtKI" + } + ], + "authority_hints": [ + "https://trustregistry.example" + ] +} +``` + +### Subordinate Statements + +Intermediaries and Trust Anchors MAY authorize their subordinates to issue or request certain credential types by placing metadata values like `openid_credential_issuer.credential_configurations_supported` or `openid_credential_verifier.dcql_query` in the Subordinate Statements. + +The meaning of such statements SHOULD be specified in ecosystem rulebooks and are out of the scope of this specification. diff --git a/specs.json b/specs.json index 0ed04f6..3a93cb2 100644 --- a/specs.json +++ b/specs.json @@ -6,7 +6,8 @@ "spec_directory": "./spec", "markdown_paths": [ "spec.md", - "future.md" + "future.md", + "federation-profile.md" ], "output_path": "./", "logo": "logo.png", From bbdc15d854c8fa436757ab23c783695f61af796f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 16:19:05 +0200 Subject: [PATCH 05/16] moved OpenID Federation to the main spec draft --- spec/future.md | 29 +++-------------------------- 1 file changed, 3 insertions(+), 26 deletions(-) diff --git a/spec/future.md b/spec/future.md index 8483914..4a351d7 100644 --- a/spec/future.md +++ b/spec/future.md @@ -1,32 +1,16 @@ ## Appendix A: Future Directions -### Credential Formats -A future version of DIIP may require support for [SD-JWT VCLD](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-sd-jwt-vcld) defined in the draft 27 of [[ref: OID4VP]]. - ### Identifiers A near-future version of DIIP will probably require support for [[ref: did:webvh]] instead of [[ref: did:web]]. ### Trust Establishment -A future version of the profile will likely refer to [[ref: OpenID Federation]]. -In [[ref: OpenID Federation]], [[ref: Issuer]]s and [[ref: Verifier]]s publish their own Entity Configurations, which include pointers to Trust Anchors. These Trust Anchors are trusted third parties that publish Entity Statements that allow for verification of the identity and the roles of the organizations. The [[ref: OIDF Wallet Architectures]] specification specifies how to use [[ref: OpenID Federation]] with Wallets. - -One way to use [[ref: OpenID Federation]] is described here as a guidance for implementers. - -- [[ref: Issuer]] [[ref: Agent]]s publish the [[ref: Issuer]]'s Entity Configurations as specified in [[ref: OIDF Wallet Architectures]]. (Simplified explanation: sign the [[ref: OID4VCI]] issuer metadata as a JWT and publish it in the `.well-known` path.) - -- [[ref: Verifier]] [[ref: Agent]]s publish the [[ref: Verifier]]'s Entity Configurations as specified in [[ref: OIDF Wallet Architectures]]. (Simplified explanation: sign the [[ref: OID4VP]] verifier metadata as a JWT and publish it in the `.well-known` path.) - -- If a [[ref: Digital Credential]] contains a [termsOfUse](https://www.w3.org/TR/vc-data-model-2.0/#terms-of-use) object with an attribute `federations`, a DIIP-compliant Wallet MUST warn the user before sharing [[ref: Digital Credential]]s or Verifiable Presentations with a [[ref: Verifier]] for which a trust chain cannot be resolved using the Trust Anchor in the value of the `federations` attribute. - -### Presentation -Note that the next [[ref: OID4VP]] draft versions may require that the `did` *Client Identifier Scheme* be prefixed in the *presentation request*. See https://github.com/openid/OpenID4VP/pull/401. - -If a new version of DIIP uses [[ref: OpenID Federation]] as the trust infrastructure, it is natural to identify parties using the same protocol and require DIIP-compliant implementations to support the `https` *Client Identifier Scheme* in [[ref: OID4VP]]. +The next version of the DIIP profile will likely require also [[ref:Wallet]]s to support [[ref: OpenID Federation]]. ### Digital Credentials API -[[ref: DC API]] is a new W3C specification. The next versions of the DIIP protocol will most likely require compliant solutions to support [[ref: DC API]]. If DIIP v4 compliant implementations support [[ref: DC API]], they should try to use that for credential issuance and verification and fall back to custom URI schemes if required. + +[[ref: DC API]] is a new W3C specification. The next versions of the DIIP protocol will most likely require compliant solutions to support [[ref: DC API]]. ### References @@ -35,10 +19,3 @@ If a new version of DIIP uses [[ref: OpenID Federation]] as the trust infrastruc [[def: did:webvh]] ~ [The did:webvh DID Method v0.5](https://identity.foundation/didwebvh/). Status: CURRENT STABLE. - -[[def: OIDF Wallet Architectures]] -~ [OpenID Federation Wallet Architectures 1.0 - draft 03](https://openid.net/specs/openid-federation-wallet-1_0-03.html). Status: Draft. - -[[def: OpenID Federation]] -~ [OpenID Federation 1.0 - draft 42](https://openid.net/specs/openid-federation-1_0-42.html). Status: draft. - From b9574d8fb0393e172b3ca97b7732a9b41cd72079 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Tue, 2 Dec 2025 16:19:35 +0200 Subject: [PATCH 06/16] Added OpenID Federation Digital Credential Profile requirements --- spec/spec.md | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/spec/spec.md b/spec/spec.md index f605685..1da69c2 100644 --- a/spec/spec.md +++ b/spec/spec.md @@ -34,9 +34,10 @@ The Decentralized Identity Interop Profile, or DIIP for short, defines requireme | Signature scheme | SD-JWT as specified in [[ref: VC-JOSE-COSE]] (20 March 2025) and [[ref: SD-JWT VC]] (draft 13) | | Signature algorithm | [[ref: ES256]] (RFC 7518 May 2015) | | Identifying [[ref: Issuer]]s, [[ref: Holder]]s, and [[ref: Verifier]]s | [[ref: did:jwk]] (Commit 8137ac4, Apr 14 2022) and [[ref: did:web]] (31 July 2024) | -| Issuance protocol | OpenID for Verifiable Credentials Issuance ([[ref: OID4VCI]]) (1.0). | -| Presentation protocol | OpenID for Verifiable Presentations ([[ref: OID4VP]]) (1.0) | +| Issuance protocol | OpenID for Verifiable Credentials Issuance 1.0 ([[ref: OID4VCI]]) (Final). | +| Presentation protocol | OpenID for Verifiable Presentations 1.0 ([[ref: OID4VP]]) (Final) | | Revocation mechanism | [[ref: IETF Token Status List]] (Draft 13, 2025-11-11) | +| Trust Establishment | [[def: OpenID Fed DCP]] (Appendix B of this profile) | The [Normative References](#normative-references) section links to the versions of specifications that DIIP-compliant implementations must support. @@ -142,7 +143,15 @@ DIIP prefers decentralized identifiers ([[ref: DID]]s) as identifiers. An entity Signatures in [[ref: Digital Credential]]s can be used to verify that the content of a credential has not been tampered with. But anyone can sign a credential and put anything in the issuer field. [[ref: Digital Credential]] ecosystems require that there is a way for a [[ref: Verifier]] to check who is the [[ref: Issuer]] of a [[ref: Digital Credential]]. Equally, a user might want to be informed about the trustworthiness of a [[ref: Verifier]] before choosing to share credentials. -The DIIP v4 profile doesn't require compliant implementations to support any trust establishment mechanism. +DIIP enables trust ecosystems to use [[ref: OpenID Fed DCP]] – a light-weight profile of the [[ref: OpenID Federation]], authred for use cases including [[ref: Wallet]]s and [[ref: Digital Credential]]s. The [[ref: OpenID Fed DCP]] specification is an appendix to this version of the DIIP profile. In the future, the [[ref: OpenID Fed DCP]] profile will probably be donated to be maintained elsewhere. + +**Requirement: DIIP-compliant [[ref: Issuer]] [[ref: Agent]]s MUST support publishing OpenID Federation Entity Configuration as defined in [[ref: OpenID Fed DCP]].** + +**Requirement: DIIP-compliant [[ref: Issuer]] [[ref: Agent]]s MUST support issuing the `fed` claim as defined in [[ref: OpenID Fed DCP]] when issuing [[ref: SD-JWT VC]] credentials.** + +**Requirement: DIIP-compliant [[ref: Issuer]] [[ref: Agent]]s MUST support issuing the `termsOfUse` attribute as defined in [[ref: OpenID Fed DCP]] when issuing [[ref: W3C VCDM]] credentials.** + +**Requirement: DIIP-compliant [[ref: Verifier]] [[ref: Agent]]s MUST support publishing OpenID Federation Entity Configuration as defined in [[ref: OpenID Fed DCP]].** ### Issuance @@ -299,10 +308,16 @@ This section consolidates in one place common terms used across open standards t ~ [Token Status List - draft 13](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/13/). Status: Internet-Draft. [[def: OID4VCI]] -~ [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). Status: Second Implementer's Draft. +~ [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). Status: Final. [[def: OID4VP]] -~ [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html). Status: Third Implementer's Draft. +~ [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html). Status: Final. + +[[def: OpenID Federation]] +~ [OpenID Federation 1.0 - draft 42](https://openid.net/specs/openid-federation-1_0.html). Status: draft. + +[[def: OpenID Fed DCP]] +~ [OpenID Federation Digital Credentials Profile - draft 0.1.0](#federation-profile). Status: draft. [[def: PAR]] ~ [RFC 9126 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126). Status: RFC - Proposed Standard. From 02bb44296eb5c6ef81ea272ccf2f6a34b261d0b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samuel=20Rinnetm=C3=A4ki?= Date: Thu, 18 Dec 2025 07:50:52 +0200 Subject: [PATCH 07/16] added the jwt_vc_issuer requirement and example, emphasized requirements --- index.html | 348 ++++++++++++++++++++++++++++++------- spec/federation-profile.md | 40 +++-- 2 files changed, 318 insertions(+), 70 deletions(-) diff --git a/index.html b/index.html index 170fdc8..c449048 100644 --- a/index.html +++ b/index.html @@ -47,10 +47,12 @@
-

§ Decentralized Identity Interop Profile v4

+

§ Decentralized Identity Interop Profile v5-draft

Profile Status: Draft

-

Latest Draft: +

Latest Release: https://FIDEScommunity.github.io/DIIP

+

Latest Draft: +https://FIDEScommunity.github.io/DIIP/draft

Editors:
Eelco Klaver (Credenco)
@@ -67,7 +69,7 @@

§ Abstract

-

The Decentralized Identity Interop Profile, or DIIP for short, defines requirements against existing specifications to enable the interoperable issuance and presentation of Digital Credentials between Issuers, Wallets, and Verifiers.

+

The Decentralized Identity Interop Profile, or DIIP for short, defines requirements against existing specifications to enable the interoperable issuance and presentation of Digital Credentials between Issuers, Holders, and Verifiers.

@@ -78,11 +80,11 @@

§ Abstract

- + - + @@ -94,15 +96,19 @@

§ Abstract

- + - + - + + + + +
Credential formatW3C VCDM 2.0 (20 March 2025) and SD-JWT VC (draft 08)W3C VCDM 2.0 (20 March 2025) and SD-JWT VC (draft 13)
Signature schemeSD-JWT as specified in VC-JOSE-COSE (20 March 2025) and SD-JWT VC (draft 08)SD-JWT as specified in VC-JOSE-COSE (20 March 2025) and SD-JWT VC (draft 13)
Signature algorithm
Issuance protocolOpenID for Verifiable Credentials Issuance (OID4VCI) (Draft 15)OpenID for Verifiable Credentials Issuance 1.0 (OID4VCI) (Final).
Presentation protocolOpenID for Verifiable Presentations (OID4VP) (Draft 28)OpenID for Verifiable Presentations 1.0 (OID4VP) (Final)
Revocation mechanismIETF Token Status List (Draft 10, 2025-04-16)IETF Token Status List (Draft 13, 2025-11-11)
Trust EstablishmentOpenID Fed DCP (Appendix B of this profile)
@@ -110,22 +116,22 @@

§ Abstract

This document is not a specification but a profile. It outlines existing specifications required for implementations to interoperate with each other. It also clarifies mandatory features for the options mentioned in the referenced specifications.

The main objective of this profile is to allow for easy adoption and use the minimum amount of functionality for a working Digital Credential ecosystem.

-

§ Status of This Document

+

§ Status of this Document

The Decentralized Identity Interop Profile v4 is a DRAFT specification under development.

The latest published DIIP profile can be found at https://FIDEScommunity.github.io/DIIP/latest.html

§ Audience

The audience of this document includes organisations aiming to issue or verify Digital Credentials, as well as the implementers of Digital Credential solutions (Wallets and Agents).

-

§ Development of the DIIP profile

+

§ Development of the DIIP Profile

Participate:
GitHub repo
-
File a bug
-
Commit history
+
File a bug
+
Commit history

The development of this interoperability profile is a collaborative process. Anyone can suggest new specifications and restrictions. The suggestions are reviewed by the community, and decisions are made through discussions.

Feel free to join the FIDES Community Discord to participate in the discussions.

There are also monthly DIIP meetings. Contact Harmen van der Kooij if you want to be invited to the meetings.

-

The authors inted to release new versions of the DIIP profile twice a year.

+

The authors intend to release new versions of the DIIP profile twice a year.

Some plans and ideas for the next version are documented in the Appendix A: Future Directions.

§ Structure of this Document

The Goals section explains the design of the DIIP profile.

@@ -135,14 +141,14 @@

§ Goals

The W3C VCDM specification defines a data model for Digital Credentials but does not prescribe standards for transport protocol, key management, authentication, query language, etc.

The (OID4VCI) and (OID4VP) protocols define the interaction between Wallets and Agents but don’t specify a data model or a credential format.

-

This interoperability profile makes selections by combining a set of specifications. It chooses standards for credential format, signature algorithm, identifying actors, and issuance and presentation protocols. Instead of saying, “We use W3C VCDM credentials signed with VC-JOSE-COSE using ES256 as the signature algorithm, OID4VCI as the issuance protocol, and OID4VP as the presentation protocol, and OpenID Federation for trust establishment,” you can just say, “We use DIIP.”

+

This interoperability profile makes selections by combining a set of specifications. It chooses standards for credential format, signature algorithm, identifying actors, and issuance and presentation protocols. Instead of saying, “We use W3C VCDM credentials signed with VC-JOSE-COSE using ES256 as the signature algorithm, OID4VCI as the issuance protocol, and OID4VP as the presentation protocol, and OpenID Federation for trust establishment”, you can just say, “We use DIIP v4”.

In addition, the DIIP profile makes selections within the specifications. When a standard allows multiple ways of implementing something, DIIP makes one of those ways mandatory. As an implementer, you don’t need to fully support all specifications to be DIIP-compliant. DIIP makes these choices to accelerate adoption and interoperability – defining the minimum required functionality.

DIIP does not exclude anything. For example, when DIIP says that compliant implementations MUST support did:jwk as an identifier of the Issuers, Holders, and Verifiers, it doesn’t say that other identifiers cannot be used. The Wallets and Agents can support other identifiers as well and still be DIIP-compliant.

-

Trust ecosystems can also easily extend DIIP by saying, “We use the DIIP profile and allow mDocs as an additional credential format.” They can also switch requirements by saying, “We use the DIIP profile but use VC-DATA-INTEGRITY as an embedded proof mechanism.”

-

The design goal for DIIP is to ensure interoperability between Agents and Wallets in cases where device binding of Digital Credentials is not required and the Wallet doesn’t need to be trusted. Issuing, holding, and presenting certifications, diplomas, licenses, permits, etc., fit into the scope of DIIP. Using a Wallet for strong customer authentication or for sharing Person Identification Data (PID) is out of DIIP’s scope, and you should look into HAIP instead.

-

§ Relationship to eIDAS regulation and HAIP profile

+

Trust ecosystems can also easily extend DIIP by saying, “We use the DIIP v4 profile and allow mDocs as an additional credential format”. They can also switch requirements by saying, “We use the DIIP v4 profile but use VC-DATA-INTEGRITY as an embedded proof mechanism”.

+

The design goal for DIIP is to ensure interoperability between Wallets and Agents in cases where device binding of Digital Credentials is not required and the Wallet doesn’t need to be trusted. Issuing, holding, and presenting certifications, diplomas, licenses, permits, etc., fit into the scope of DIIP. Using a Wallet for strong customer authentication or for sharing Person Identification Data (PID) is out of DIIP’s scope, and you should look into HAIP instead.

+

§ Relationship to eIDAS Regulation and HAIP Profile

In the context of the European eIDAS regulation (eIDAS) and its Architecture and Reference Framework (ARF), the DIIP profile is a profile for “regular” digital credentials, “non-qualified electronic attestations of attributes”.

-

Digital Agents and Wallets may support both DIIP and the OpenID4VC High Assurance Interoperability Profile (HAIP). HAIP is targeted for high-assurance use cases where it is important to bind the credentials to the Holder's private key (device binding). DIIP is the profile for other use cases.

+

Wallets and Agents may support both DIIP and the OpenID4VC High Assurance Interoperability Profile (HAIP). HAIP is targeted for high-assurance use cases where it is important to bind the credentials to the Holder's private key (device binding). DIIP is the profile for other use cases.

The standards used in the DIIP profile are the same ones that the ARF uses, but DIIP makes different choices to HAIP in some areas where OID4VCI and OID4VP provide optionality.

While DIIP is a standalone profile and enables interoperability on it’s own, it is designed to build upon and integrate with the EUDI wallet. Therefore, DIIP implementers who want to integrate with the EUDI Wallet should support HAIP and the implementation regulations issued by the European Commission.

§ Profile

@@ -150,8 +156,7 @@

§ Profile

§ Credential Format

The W3C Verifiable Credential Data Model (W3C VCDM) defines structure and vocabulary well suited for Digital Credentials in DIIP’s scope. For example, the Open Badges 3 credentials use W3C VCDM as the data format.

The SD-JWT-based Verifiable Credentials specification (SD-JWT VC) defines a credential format that are serialized in JSON Web Tokens (JWTs) and enable selective disclosure. SD-JWT VC is used as a credential format for person identification data (PID) in HAIP and ARF (in addition to mDocs).

-

W3C VCDM recommends using Securing Verifiable Credentials using JOSE and COSE (VC-JOSE-COSE) as an enveloping proof mechanism and -Verifiable Credential Data Integrity 1.0 (VC-DATA-INTEGRITY) as an embedded proof mechanism.

+

W3C VCDM recommends securing Verifiable Credentials using JOSE and COSE (VC-JOSE-COSE) as an enveloping proof mechanism and Verifiable Credential Data Integrity 1.0 (VC-DATA-INTEGRITY) as an embedded proof mechanism.

To keep things as simple as possible, DIIP requires implementations to use SD-JWT as the mechanism to secure also W3C VCDM-based credentials.

Requirement: DIIP-compliant implementations MUST support SD-JWT VC as a credential format.

Requirement: DIIP-compliant implementations MUST support W3C VCDM and more specifically Securing JSON-LD Verifiable Credentials with SD-JWT as specified in (VC-JOSE-COSE).

@@ -159,11 +164,15 @@

The DIIP profile chooses one key type Secp256r1 and one signature method ES256 that all implementations must support.

Requirement: DIIP-compliant implementations MUST support ES256 (ECDSA using Secp256r1 curve and SHA-256 message digest algorithm).

§ Identifiers

-

DIIP prefers decentralized identifiers (DIDs) as identifiers. An entity identified by a DID publishes a DID Document, which can contain useful metadata about the entity, e.g., various endpoints. There are many DID Methods defined. The DIIP profile requires support for two of them: did:jwk and did:web. In many use cases, organizations are identified by did:web, and the natural persons are identified by did:jwk.

+

DIIP prefers decentralized identifiers (DIDs) as identifiers. An entity identified by a DID publishes a DID Document, which can contain useful metadata about the entity, e.g., various endpoints. There are many DID methods defined. The DIIP profile requires support for two of them: did:jwk and did:web. In many use cases, organizations are identified by did:web, and the natural persons are identified by did:jwk.

Requirement: DIIP-compliant implementations MUST support did:jwk and did:web as the identifiers of the Issuers, Holders, and Verifiers.

§ Trust Establishment

-

Signatures in Digital Credentials can be used to verify that the content of a credential has not been tampered with. But anyone can sign a credential and put anything in the issuer field. Digital Credential ecosystems require that there is a way for a Verifier to check who the Issuer or a Digital Credential is. Equally, a user might want to be informed about the trustworthiness of a Verifier before choosing to release credentials.

-

The DIIP v4 profile doesn’t require compliant implementations to support any trust establishment mechanism.

+

Signatures in Digital Credentials can be used to verify that the content of a credential has not been tampered with. But anyone can sign a credential and put anything in the issuer field. Digital Credential ecosystems require that there is a way for a Verifier to check who is the Issuer of a Digital Credential. Equally, a user might want to be informed about the trustworthiness of a Verifier before choosing to share credentials.

+

DIIP enables trust ecosystems to use OpenID Fed DCP – a light-weight profile of the OpenID Federation, authred for use cases including Wallets and Digital Credentials. The OpenID Fed DCP specification is an appendix to this version of the DIIP profile. In the future, the OpenID Fed DCP profile will probably be donated to be maintained elsewhere.

+

Requirement: DIIP-compliant Issuer Agents MUST support publishing OpenID Federation Entity Configuration as defined in OpenID Fed DCP.

+

Requirement: DIIP-compliant Issuer Agents MUST support issuing the fed claim as defined in OpenID Fed DCP when issuing SD-JWT VC credentials.

+

Requirement: DIIP-compliant Issuer Agents MUST support issuing the termsOfUse attribute as defined in OpenID Fed DCP when issuing W3C VCDM credentials.

+

Requirement: DIIP-compliant Verifier Agents MUST support publishing OpenID Federation Entity Configuration as defined in OpenID Fed DCP.

§ Issuance

The issuance of Digital Credentials from the Issuer to the Holder's Wallet is done along the OID4VCI specification. Other protocols exist, but OID4VCI is very broadly supported and also required by HAIP.

§ OID4VCI

@@ -172,7 +181,7 @@

§ OID4VCI

In many situations, Digital Credentials are issued on the Issuer's online service (website). This online service may have already authenticated and authorized the user before displaying the credential offer. Another authentication or authorization is not needed in those situations.

Authorization Code Flow provides a more advanced way of implementing credential issuance. Proof Key for Code Exchange (PKCE) defines a way to mitigate against authorization code interception attack. Pushed authorization request (PAR) allows clients to push the payload of an authorization request directly to the authorization server. These features may be needed in higher assurance use cases or for protecting privacy.

Requirement: DIIP-compliant implementations MUST support both Pre-Authorized Code Flow and Authorization Code Flow.

-

Requirement: DIIP-compliant implementations MUST support the Transaction Code when using Pre-Authorized Code Flow.

+

Requirement: DIIP-compliant implementations MUST support the tx_code when using Pre-Authorized Code Flow.

Requirement: DIIP-compliant Wallets MUST NOT assume the Authorization Server is on the same domain as the Issuer.

Requirement: DIIP-compliant implementations MUST support PKCE with Code Challenge Method Parameter S256 to prevent authorization code interception attacks.

Requirement: DIIP-compliant implementations MUST support PAR with the Issuer's Authorization Server using require_pushed_authorization_requests set to true ensuring integrity and authenticity of the authorization request.

@@ -197,7 +206,7 @@

§ OID4VP

Using OID4VP, the Holders can also present cryptographically verifiable claims issued by third-party Issuers, such that the Verifier can place trust in those Issuers instead of the subject (Holder).

OID4VP supports scenarios where the Authorization Request is sent both when the Verifier is interacting with the Holder using the device that is the same or different from the device on which requested Digital Credentials are stored.

Requirement: DIIP-compliant implementations MUST support both Same-device Flow and Cross-device Flow.

-

According to OID4VP, rhe Verifier may send an Authorization Request using either of these 3 options:

+

According to OID4VP, the Verifier may send an Authorization Request using either of these 3 options:

§ Appendix A: Future Directions

-

§ Credential Formats

-

A future version of DIIP may require support for SD-JWT VCLD defined in the draft 27 of OID4VP.

§ Identifiers

A near-future version of DIIP will probably require support for did:webvh instead of did:web.

§ Trust Establishment

-

A future version of the profile will likely refer to OpenID Federation. -In OpenID Federation, Issuers and Verifiers publish their own Entity Configurations, which include pointers to Trust Anchors. These Trust Anchors are trusted third parties that publish Entity Statements that allow for verification of the identity and the roles of the organizations. The OIDF Wallet Architectures specification specifies how to use OpenID Federation with Wallets.

-

One way to use OpenID Federation is described here as a guidance for implementers.

- -

§ Presentation

-

Note that the next OID4VP draft versions may require that the did Client Identifier Scheme be prefixed in the presentation request. See https://github.com/openid/OpenID4VP/pull/401.

-

If a new version of DIIP uses OpenID Federation as the trust infrastructure, it is natural to identify parties using the same protocol and require DIIP-compliant implementations to support the https Client Identifier Scheme in OID4VP.

+

The next version of the DIIP profile will likely require also Wallets to support OpenID Federation.

§ Digital Credentials API

-

DC API is a new W3C specification. The next versions of the DIIP protocol will most likely require compliant solutions to support DC API. If DIIP v4 compliant implementations support DC API, they should try to use that for credential issuance and verification and fall back to custom URI schemes if required.

+

DC API is a new W3C specification. The next versions of the DIIP protocol will most likely require compliant solutions to support DC API.

§ References

DC API
Digital Credentials. Status: Draft Community Group Report.
did:webvh
The did:webvh DID Method v0.5. Status: CURRENT STABLE.
-
OIDF Wallet Architectures
-
OpenID Federation Wallet Architectures 1.0 - draft 03. Status: Draft.
-
OpenID Federation
-
OpenID Federation 1.0 - draft 42. Status: draft.
+

§ Appendix B: OpenID Federation Digital Credentials Profile

+

§ Introduction

+

This specification profiles OpenID Federation OpenID Federation for use with digital credentials, specifically focusing on credential issuance via OpenID for Verifiable Credential Issuance OID4VCI and credential presentation via OpenID for Verifiable Presentations OID4VP.

+

The profile simplifies federation usage by limiting scope to trust chain resolution and metadata discovery, while omitting more complex features such as federation policies and trust marks.

+

§ Scope

+

This profile applies to:

+
    +
  • Credential issuers publishing OID4VCI metadata
    • +
  • Credential verifiers publishing verifier metadata
    • +
  • Wallets resolving trust chains to establish trust in issuers and verifiers
    • +
+

This profile does not apply to and does not require conforming implementations to support:

+
    +
  • Chapter 6 (Federation Policy) of OpenID Federation
    • +
  • Chapter 7 (Trust Marks) of OpenID Federation
    • +
  • Chapter 12 (OpenID Connect Client Registration) of OpenID Federation
    • +
+

§ Terminology

+

This specification uses the terms defined in OpenID Federation OpenID Federation, OpenID for Verifiable Credential Issuance OID4VCI, OpenID for Verifiable Presentations OID4VP, and SD-JWT VC SD-JWT VC.

+

Entity Identifier: As defined in OpenID Federation, a URL that uniquely identifies a federation entity.

+

Entity Configuration: As defined in OpenID Federation, a signed JWT published at the Entity Identifier’s /.well-known/openid-federation endpoint containing metadata and authority hints.

+

Trust Chain: As defined in OpenID Federation, a sequence of Entity Statements from a Leaf Entity through intermediate entities to a Trust Anchor.

+

Issuer: The role of the entity issuing credentials as defined in W3C VCDM

+

Credential Issuer: The technical service used to issue credentials as defined in OID4VCI

+

Verifier: The entity that requests, receives, and validates Presentations as defined in OID4VCI. Note that this specification does not distinguish the role and the technical service of the verifier the same way it does for Issuer and Credential Issuer. For the purposes of this specification Verifier may refer to either the role or the technical service. (Thus, the reference to the definition in OID4VCI and not the one in OID4VP.)

+

§ Credential Issuance

+

§ Entity Identifier

+

Requirement: The Credential Issuer MUST use the value of the credential_issuer in its OID4VCI issuer metadata as its Entity Identifier.

+

The Credential Issuer’s Entity Configuration can be found by appending the string /.well-known/openid-federation to the Entity Identifier.

+

§ Issuer Metadata Publication

+

Requirement: The Credential Issuer MUST place the OpenID4VCI issuer metadata into the Entity Configuration, in the openid_credential_issuer property.

+

Requirement: The Credential Issuer MUST place the public key material of the keys it uses to sign Digital Credentials in the jwt_vc_issuer property. The jwt_vc_issuer property MUST include the jwks property that contains the Issuer’s JSON Web Key Set as defined in RFC7517. (The jwt_vc_issuer property MUST NOT include the jwks_uri property.)

+

Requirement: If the openid_credential_issuer property is found in the Entity Configuration, the Wallet MUST use only it and ignore the issuer metadata published in the well-known location defined in OID4VCI.

+

The Credential Issuer MAY place additional metadata into the federation_entity Entity Type Identifier.

+

Requirement: The metadata in the openid_credential_issuer property MUST override the metadata in the federation_entity property. For example, if both openid_credential_issuer.display.name and federation_entity.organization_name exist, the Wallet MUST show the value of openid_credential_issuer.display.name as the name of the issuer.

+

§ Example: Credential Issuer Entity Configuration

+

The following JSON document is a non-normative example of the decoded payload of a Credential Issuer’s Entity Configuration.

+
{
+  "iss": "https://credential-issuer.example",
+  "sub": "https://credential-issuer.example",
+  "iat": 1616239022,
+  "exp": 1616239322,
+  "metadata": {
+    "federation_entity": {
+      "organization_name": "Example Credential Issuer",
+      "contacts": ["support@credential-issuer.example"]
+    },
+    "openid_credential_issuer": {
+      "issuer": "https://credential-issuer.example",
+      "display": [
+        {
+          "name": "Example Issuer",
+          "locale": "en-US",
+          "logo": {
+            "uri": "https://credential-issuer.example/logo.png",
+            "alt_text": "Example Logo"
+          }
+        }
+      ],
+      "credential_issuer": "https://credential-issuer.example",
+      "authorization_endpoint": "https://credential-issuer.example/authorize",
+      "authorization_servers": ["https://credential-issuer.example/authorize"],
+      "credential_endpoint": "https://credential-issuer.example/credential",
+      "credential_configurations_supported": {
+        "sd_jwt_vc_example": "..."
+      }
+    },
+    "jwt_vc_issuer": {
+      "jwks": [
+        {
+          "kty": "EC",
+          "kid": "MJ2BW-rNshp9sjh3SvwnBIkEsYsU92xVtC3-Fv_lcKc",
+          "alg": "ES256",
+          "crv": "P-256",
+          "x": "JTEE5QghmkA_-7_pZoKIluRzGNvQGtzmpNvb_nAswhE",
+          "y": "A_iBfIseHsdfE7CmI3lIYtKMdfyXXOIpPX_o6O0h0wY",
+          "use": "sig"
+        }
+      ]
+    }
+  },
+  "jwks": [
+    {
+      "kty": "EC",
+      "kid": "MJ2BW-rNshp9sjh3SvwnBIkEsYsU92xVtC3-Fv_lcKc",
+      "alg": "ES256",
+      "crv": "P-256",
+      "x": "JTEE5QghmkA_-7_pZoKIluRzGNvQGtzmpNvb_nAswhE",
+      "y": "A_iBfIseHsdfE7CmI3lIYtKMdfyXXOIpPX_o6O0h0wY",
+      "use": "sig"
+    }
+  ],
+  "authority_hints": [
+    "https://trustregistry.example"
+  ]
+}
+
+

The JWKS in the jwt_vc_issuer property contains information about the keys used to sign Digital Credentials. The JWKS on the root level of the Entity Configuration contains information about the key used to sign the Entity Configuration. In the example, the same key is used, but the keys MAY be different.

+

§ SD-JWT VC Credentials

+

Requirement: When the Issuer issues credentials in the SD-JWT VC format, the Issuer MUST place its Entity Identifier in the fed claim of the credential.

+
§ Example: SD-JWT VC with Federation Claim
+

The following non-normative example shows a decoded payload of an SD-JWT VC credential with the fed claim:

+
{
+  "iss": "https://credential-issuer.example",
+  "fed": "https://credential-issuer.example",
+  "iat": 1683000000,
+  "exp": 1883000000,
+  "vct": "https://credentials.example.com/identity_credential",
+  "is_over_65": true,
+  "address": {
+    "street_address": "123 Main St",
+    "locality": "Anytown",
+    "region": "Anystate",
+    "country": "US"
+  }
+}
+
+

§ W3C VCDM Credentials

+

Requirement: When the Issuer issues credentials in the W3C VCDM format, the Issuer MUST place a termsOfUse property into the credential. The type of this termsOfUse property MUST be the string OpenIDFederation and the policyId MUST be the Issuer’s Entity Identifier.

+
§ Example: W3C VCDM Credential with termsOfUse
+

The following non-normative example illustrates the use of the termsOfUse property:

+
{
+  "@context": [
+    "https://www.w3.org/ns/credentials/v2"
+  ],
+  "id": "urn:uuid:c65d364e-2560-4e08-be03-9c3d944d609d",
+  "type": [
+    "VerifiableCredential"
+  ],
+  "issuer": "did:web:credential-issuer.example",
+  "validFrom": "2025-12-01T00:00:00Z",
+  "validUntil": "2028-12-31T23:59:59Z",
+  "credentialSubject": {
+  },
+  "termsOfUse": {
+    "type": "OpenIDFederation",
+    "trustFramework": "Example Federation",
+    "policyId": "https://credential-issuer.example"
+  }
+}
+
+

§ Note on Credential Issuer vs. Issuer

+

The Issuer defined in the digital credential (the value of the iss claim in SD-JWT VC credentials or the value of the id of the issuer property in W3C VCDM credentials) is not necessarily the same entity as the Credential Issuer defined in the property credential_issuer in the OID4VCI metadata.

+

For example, the OpenID Federation Entity Identifier of the Issuer of the credential could be https://university-of-utopia.example.edu and the OpenID Federation Entity Identifier of the Credential Issuer could be https://credentials.ministryofeducation.example.edu.

+

If the Issuer chooses to make this kind of distinction between the entity issuing the credential and the technical service used for issuance, it is RECOMMENDED that the Entity Configuration of the technical service has an authority_hints value pointing to the Issuer’s Entity Identifier and the Issuer publishes a Subordinate Statement about the technical service.

+

§ Credential Presentation and Verification

+

§ Client Identifier Scheme

+

Requirement: The Verifier MUST use the openid_federation: prefix as defined in OID4VP Section 5.9.3.

+

§ Verifier Metadata Publication

+

Requirement: The Verifier MUST place verifier metadata into the Entity Configuration, in the openid_credential_verifier property.

+

§ Trust Establishment

+

Requirement: To establish trust with the issuer (ensure that the issuer can be trusted), the Verifier MUST resolve the Trust Chain from the issuer’s Entity Configuration until it finds a Federation Entity it trusts.

+

§ Example: Verifier Entity Configuration

+

The following JSON document is a non-normative example of the decoded payload of a Verifier’s Entity Configuration.

+
{
+  "iss": "https://credential-verifier.example",
+  "sub": "https://credential-verifier.example",
+  "iat": 1616239023,
+  "exp": 1616239323,
+  "metadata": {
+    "federation_entity": {
+      "organization_name": "Example Credential Verifier",
+      "contacts": ["support@credential-verifier.example"]
+    },
+    "openid_credential_verifier": {
+      "jwks": {
+        "keys": [
+          {
+            "kty": "EC",
+            "crv": "P-256",
+            "x": "f83OJ3D2xF4Z1s3QpLQe4qVb8K7q6y1v3z4Yb6k9J0",
+            "y": "x_FEzRu9q3u4bWz5n9X2L4q1U8T7c6v5s2d1a0b3C4",
+            "alg": "ES256",
+            "use": "enc",
+            "kid": "ec-key-1"
+          }
+        ]
+      },
+      "encrypted_response_enc_values_supported": [
+        "A128GCM",
+        "A192GCM",
+        "A256GCM"
+      ],
+      "vp_formats_supported": {
+        "dc+sd-jwt": {
+          "sd-jwt_alg_values": ["ES256"],
+          "kb-jwt_alg_values": ["ES256"]
+        }
+      }
+    }
+  },
+  "jwks": [
+    {
+      "kty": "EC",
+      "kid": "y4nC8uTvcM5uJxOIvUqFjXb2EA6xPGdnt8zvjW94m6U",
+      "alg": "ES256",
+      "crv": "P-256",
+      "x": "K6dA9ayt4P8xBN6SFiCZYOI2qeaFda7VV5wnmHWcl7w",
+      "y": "CdE30dUX0geK4NL8IMC9u-rRMOLC9WaScJIGK5rxtKI"
+    }
+  ],
+  "authority_hints": [
+    "https://trustregistry.example"
+  ]
+}
+
+

§ Subordinate Statements

+

Intermediaries and Trust Anchors MAY authorize their subordinates to issue or request certain credential types by placing metadata values like openid_credential_issuer.credential_configurations_supported or openid_credential_verifier.dcql_query in the Subordinate Statements.

+

The meaning of such statements SHOULD be specified in ecosystem rulebooks and are out of the scope of this specification.

@@ -362,15 +562,15 @@

§ Referen @@ -419,7 +649,7 @@

§ Referen undefined - +