DIIP v5

[samuelmr]

This PR updates the OID4VC, SD-JWT VC, and Token Status List versions.

It also adds OPTIONAL requirements for issuer and verifier agents to support OpenID Federation (publish Entity Configuration files).

This version includes a draft of OpenID Federation Digital Credentials Profile – likely to be carved out as a separate specification in the future.

[github-actions]

🚀 Preview deployment successful!

📄 Preview URL: https://FIDEScommunity.github.io/DIIP/pr/pr-84
📝 PR: #84
🔄 Status: Ready for review

This preview will be updated automatically when you push new commits to this PR.

The preview will be removed when the PR is closed or merged.

[ubamrein]

Shouldn't we point towards the method(s) listed under https://openid.net/specs/openid-federation-1_0.html#name-obtaining-federation-entity ? It is part of openid-federation, and adding this here could potentially deviate and/or confuse people

[samuelmr]

Fixed in b3d496d

[ubamrein]

I'm still not sure what this is supposed to mean. organization_name and display.name have different semantic meanings according to the specification (https://openid.net/specs/openid-federation-1_0.html#name-informational-metadata-exte and https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-12.2.4-2.10.2.1).

In VCI we have for display.name

String value of a display name for the Credential Issuer.

In oidf organization_name is defined as:

A human-readable name representing the organization owning this Entity. If the owner is a physical person, this MAY be, for example, the person's name. Note that this information will be publicly available

It is even more confusing, as oidf does have a semantically similar claim display_name:

A human-readable name of the Entity to be presented to the End-User.

If we want to have either organization_name or display.name then it should not be for example but explicitly define that this particular property will be overwritten.

[samuelmr]

I agree that we should remove the optionality and specify how all implementations should work.

(When I originally wrote the proposal, I was leaning towards just specifying priority/precedence rules for data coming from various sources. When the wallet needs to show the user "Org X is requesting information from your wallet", it could fetch the name of the requesting organization from any of the attributes listed above – even if they have different definitions.)

[samuelmr]

Should we just require Issuers and Verifiers to populate display_name as specified in https://openid.net/specs/openid-federation-1_0.html#name-informational-metadata-exte amd Wallets to show that to the users?

[samuelmr]

Or is it simpler to use openid_credential_issuer.display.name since that's what's being used if there is no OpenID Federation involved?

[samuelmr]

OID4VCI metadata supports localization, but there seems to be no similar metadata for the Verifiers...

[samuelmr]

Decided to use *federation_entity.display_name` in b3d496d.

[samuelmr]

@TimoGlastra, @eklaver, @k00ij, @nklomp: can you review the latest version so that we can publish it on Jan 15th as planned?

https://fidescommunity.github.io/DIIP/pr/pr-84/

[TimoGlastra]

Would it be possible that we publish DIIP on Jan 15 as a 'release candidate', and we give e.g one or 2 months of time to implement and gather feedback and make adjustments based on that. Since no one already has this implemented on day one, I think giving a window to iterate on the document makes sense, and it gives implementers a heads up that things may change if they were incorrect. It's not intended to be used to push new features

[samuelmr]

Would it be possible that we publish DIIP on Jan 15 as a 'release candidate', and we give e.g one or 2 months of time
to implement and gather feedback and make adjustments based on that.

Thanks for the suggestion. I'd be interested to hear what others think.

Remember that there are no sanctions on anyone if they are not compliant on day one.

The main requirements (especially, OID4VC 1.0, also status lists and SD-JWT VC version updates) have been public since the end of October (#78). All vendors should have already had plenty of time to implement those.

In the last DIIP meetup, we decided to make the OpenID Federation requirements optional because the specification for them was written so late that nobody would have had time to implement them by January 15th.

[eklaver]

Thanks for the update! I will review it today.

I agree with Timo that during implementation the real questions and discussions come up, but on the other hand I don't mind just releasing the new version. Updates can always be done in the next version.

[selfissued]

I suggest referencing the OpenID Federation Wallet Architectures specification for the definitions from it that this specification is using, such as openid_wallet_provider, openid_credential_issuer, and openid_credential_verifier.

[samuelmr]

I suggest referencing the OpenID Federation Wallet Architectures specification for the definitions from it that this specification is using, such as openid_wallet_provider, openid_credential_issuer, and openid_credential_verifier.

Thanks for the suggestion!

This specification doesn't use the definition openid_wallet_provider.
The inspiration to openid_credential_issuer comes from https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata- and openid_credential_verifier is a natural counterpart to that.

One could argue that this specification and the OpenID Federation Wallet Architectures specification are conflicting since both define the same Entity Types openid_credential_issuer and openid_credential_verifier.

Another argument is that since both specifications use the Entity Type definitions similarly, it would be beneficial for one spec to refer to the other. (I believe this is the argument you're making.)

Currently, the chapters 6.2, 6.3, and 7.1 of OpenID Federation Wallet Architectures are quite brief. Referring to that specification as a normative definition for the abovementioned Entity Types would not make this specification easier to understand or maintain. It would make it somewhat more difficult for implementers to look at another spec instead of having everything in one place. It would also introduce a risk that the OpenID Federation Wallet Architectures specification changes the requirements for the metadata of these Entity Types in a way that is no longer aligned with this spec.

Would you be happy with a non-normative reference? (To give credit where it's due.)

[selfissued]

I think the chances of anyone deciding to change the Entity Type Identifers openid_credential_issuer and openid_credential_verifier is approximately zero because they're in production use in the Italian EUDI Wallet, among other places. I'd prefer a normative reference but that's up to the editors of this spec.

As long as we're talking about references, you might also update the OpenID Federation 1.0 reference either to draft 46 or omit the draft number, since it's essentially done.

[peppelinux]

I must apologies if I didn't get which kind of conflict we may have between the two specification. Federation Wallet has born before and I suppose that DIIP federation was inspired by federation wallet

if we may individuate the extensions that DIIP proposes we may converge in a single openid specification. I would like to get them summarized (with reference to DIIP specs) to facilitate their developments

[selfissued]

Some of the references to other specs need to be updated. For instance, the VCDM and VC-JOSE-COSE specs are now W3C recommendations and dated 15 May 2025. Token Status list is now at draft 15. All the references should be looked at.

BTW, should I be making comments on this PR or filing issues?

[TimoGlastra]

Ideally DIIP references the Federation Wallet Architectures document. While DIIP is a specific profile, I see benefit in a baseline for using OpenID Federation with wallets, OpenID4VC and common credential formats. One of the reasons we decided to create a custom definition in DIIP is that the wallet architectures spec is missing some parts, and adding it to DIIP gives some more flexibility to experiment at the moment.

[selfissued]

@TimoGlastra you wrote:

the wallet architectures spec is missing some parts

Now that the Federation Wallet Architectures spec is being actively worked on again, it would be super useful to know what those missing parts are. Could you please file issues for the missing parts at https://github.com/openid/federation-wallet?

Thanks!

[samuelmr]

Some of the references to other specs need to be updated. For instance, the VCDM and VC-JOSE-COSE specs are now W3C recommendations and dated 15 May 2025. Token Status list is now at draft 15. All the references should be looked at.

Thanks!

b559477 updates the references to VCDM, VC-JOSE-COSE, and Token Status List.

BTW, should I be making comments on this PR or filing issues?

If something still needs to be changed for DIIP v5, please comment here. Otherwise, please open a new discussion or an issue.

[samuelmr]

if we may individuate the extensions that DIIP proposes we may converge in a single openid specification.

I agree that it would be good to merge the specs.

Let's work together to combine the best parts of both.

My shortlist of differences:

• Wallet Architectures spec doesn't describe how the verifier can trust the issuer (Add trust establishment between verifier and issuer openid/federation-wallet#51)
• Do we really expect OpenID Federation to be used for purposes mentioned in the Wallet Architectures spec chapters 8.1, 8.2, 8.4, and 8.5? I think most of these use cases are inspired by the EUDI architecture, and they are already being solved using other mechanisms.
• Wallet Architectures spec has lots of explanatory text and diagrams. I prefer clear and concise requirements for implementers.

Perhaps you can also review the OpenID Federation Digital Credentials Profile and see if there are things you find nice or useful.

[k00ij]

The remaining discussions are about trust establishment. We agreed that this would be optional in DIIPv5 so it is not a showstopper to publish DIIPv5. Below a slightly updated text for section 3.1. @samuelmr if you update that I will approve the PR and DIIPv5 can published as Final version. In parallel we can continue the discussion on trust establishment/OID Fed.

3.1 Relationship to eIDAS Regulation and HAIP Profile

The DIIP profile is intended to be complementary to the OpenID4VC High Assurance Interoperability Profile (HAIP). Both profiles build on the OpenID for Verifiable Credentials (OID4VC) specifications, but they address different interoperability scopes and assurance needs.

DIIP is an interoperability profile that includes the W3C Decentralized Identifiers (DID) specification and the Verifiable Credentials Data Model (VCDM) 2.0. These specifications are not part of the HAIP interoperability profile.

DIIP explicitly targets multi-party interoperability scenarios in cross-domain and global ecosystems. These scenarios require identifier-agnostic and Linked Data–based interoperability, with a focus on business wallets, rather than personal wallets only. This makes DIIP particularly relevant for ecosystems such as Gaia-X, Catena-X, IDSA and SIMPL (Data Spaces), UNTP and CIRPASS-2 (Digital Product Passports), MOSIP (Digital Public Infrastructure), EU CitiVERSE (Local Digital Twins), Open Badges (Skills/Certificates/Diplomas), and the Swiss E-ID Ecosystem.

In the European context, HAIP is typically used for high-assurance use cases, including those involving Qualified Electronic Attestations of Attributes (QEAA). DIIP can be applied to use cases with lower assurance requirements, for example where Electronic Attestations of Attributes (EAA) are sufficient, or where device binding or qualified attestation is not required, while still enabling interoperability based on the same OID4VC foundations.

While DIIP is a standalone interoperability profile and enables interoperability on its own, it is designed to coexist with and complement HAIP. Wallets and agents may therefore support both profiles, selecting the appropriate one based on the assurance requirements of a given use case.

Wallet providers are encouraged to implement both HAIP and DIIP, enabling them to support a broad range of assurance levels, use cases, and ecosystems using a common OpenID4VC foundation.

[samuelmr]

Below a slightly updated text for section 3.1. @samuelmr if you update that I will approve the PR and DIIPv5 can published

Done.

[k00ij]

As agreed in DIIP meetup#27, 27-12-2025. Trust management part is optional and can be further discussed and tested.