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.
| Revocation mechanism | -IETF Token Status List (Draft 10, 2025-04-16) | +IETF Token Status List (Draft 10, 2025-04-16) and Bitstring Status List (15 May 2025) |
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.
-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
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).
-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.
The Goals section explains the design of the DIIP profile.
@@ -135,14 +135,14 @@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.
-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.
+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.
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 +
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.
@@ -159,10 +159,10 @@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).
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.
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.
+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.
The DIIP v4 profile doesn’t require compliant implementations to support any trust establishment mechanism.
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.
@@ -172,7 +172,7 @@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.
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:
Expiration algorithms using validFrom and 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 Holders and Verifiers.
Requirement: DIIP-compliant implementations MUST support checking the validity status of a Digital Credential using validFrom and validUntil when they are specified.
The IETF Token Status List defines a mechanism, data structures, and processing rules for representing the status of Digital Credentials (and other “Tokens”). The statuses of Tokens are conveyed via a bit array in the Status List. The Status List is embedded in a Status List Token.
-The Bitstring Status List is based on the same idea as the IETF Token Status List and is simpler to implement since it doesn’t require signing of the status list. The IETF Token Status List may gain more support since it is recommended by HAIP.
-Requirement: DIIP-compliant implementations MUST support IETF Token Status List as a status list mechanism.
+The IETF Token Status List defines a mechanism, data structures, and processing rules for representing the status of Digital Credentials (and other “Tokens”). The statuses of Tokens are conveyed via a bit array in the Status List. The Status List is embedded in a Status List Token. A credential can reference one status list.
+The Bitstring Status List is based on the same idea as the IETF Token Status List and is simpler to implement since it doesn’t require signing of the status list. This type of status list is defined for W3C VCDM credentials and allows implementation of multiple status lists.
+The IETF Token Status List may gain more support since it is recommended by HAIP.
+Requirement: DIIP-compliant implementations MUST support both IETF Token Status List and Bitstring Status List as a status list mechanism.
+The IETF Token Status List specification chapter 6 specifies a status claim containing the reference to the IETF Token Status List implementation.
Requirement: DIIP-compliant implementations MUST support the IETF Token Status List status claim at the root of JSON, JWT, SD-JWT, JOSE or COSE encoded credentials.
Implementors that use linked data proofs to secure the credential MUST supply a relevant @context to include the IETF Token Status List status claim. SD-JWT implementations MUST NOT make the status claim selectively disclosable.
The W3C VCDM specification defines a credentialStatus attribute to encode token status references. The Bitstring Status List specification indicates how to fill this structure. SD-JWT implementations MUST NOT make this attribute selectively disclosable.
Requirement: DIIP-compliant implementations MUST support the credentialStatus attribute of credentials according to the W3C VCDM specification.
+Requirement: DIIP-compliant implementations MUST be able to interpret credentialStatus attributes following the Bitstring Status List specification.
Instead of using the IETF Token Status List status claim, implementators can choose to add a W3C VCDM credentialStatus attribute entry to encode the IETF Token Status List status list reference as follows:
{
+ ...
+ "credentialStatus": [
+ ...,
+ {
+ "type": "statuslist+jwt",
+ "idx": 1242,
+ "uri": "https://example.com/statuslists/1"
+ }
+ ]
+}
+Requirement: DIIP-compliant implementations MUST be able to interpret credentialStatus attribute entries following the IETF Token Status List specification with type statuslist+jwt.
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.
.well-known path.)
Verifier Agents publishi the Verifier's Entity Configurations as specified in OIDF Wallet Architectures. (Simplified explanation: sign the OID4VP verifier metadata as a JWT and publish it in the .well-known path.)
Verifier Agents publish the Verifier's Entity Configurations as specified in OIDF Wallet Architectures. (Simplified explanation: sign the OID4VP verifier metadata as a JWT and publish it in the .well-known path.)
If a Digital Credential contains a termsOfUse object with an attribute federations, a DIIP-compliant Wallet MUST warn the user before sharing Digital Credentials or Verifiable Presentations with a Verifier for which a trust chain cannot be resolved using the Trust Anchor in the value of the federations attribute.