V5 draft #79

samuelmr · 2025-12-02T14:31:17Z

This PR updates the versions of the OID4VC protocols, SD-JWT VC draft version, IETF Token Status List draft version, and adds OpenID Federation Digital Credentials Profile as an appendix (content as discussed in #71 ).

…ft 08 to draft 13 and IETF Token Status List from draft 10 to draft 13

samuelmr · 2025-12-02T14:34:20Z

@nklomp, the preview creation fails with the error:

Error: Error message: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

TimoGlastra

Left some comments, thanks for creating the PR!

I think we should define more on the relation between the iss/issuer field and the federation entity, since the way the profile is currently defined goed against all standard processing logic for credentials.

In our platform if we verify a credential that includes the iss field with a did:web, we would want to ensure that there is some cryptographic link between the cred and the did. Even if federation is used. Can we do anything about that?

I think it's similar to the status list provider being different from the credential issuer, that is fine, but there should be some cryptographic link between them.

TimoGlastra · 2025-12-02T14:38:28Z

spec/federation-profile.md

+This profile applies to:
+
+- Credential issuers publishing OID4VCI metadata
+- Credential verifiers publishing verifier metadata


For consistency

Suggested change

- Credential verifiers publishing verifier metadata

- Credential verifiers publishing OID4VP metadata

The inconsistency is intentional. See Terminology: "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."

I'm not sure what that has to do with naming it OID4VP vs verifier metadata?

Sorry. I misread the suggestion.

The OID4VP uses the term "Verifier metadata" (in chapter 5.9).
The OID4VCI uses the term "Credential Issuer Metadata" (in 12.2).

Should we use those terms?

Suggest to combine OID4VP verifier metadata
And OID4VCI Credential Issuer Metadata

TimoGlastra · 2025-12-02T14:39:58Z

spec/federation-profile.md

+
+#### Scope
+
+This profile applies to:


Should this include:

credential verifiers establishing trust in credential issuers

Perhaps. Maybe we also need a requirement along the lines of "The conformant Verifier Agents MUST support resolving the trust chains from the Entity Configuration of the Issuer of a Digital Credential".

TimoGlastra · 2025-12-02T14:40:17Z

spec/federation-profile.md

+- 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:


Should this include:

credential issuers establishing trust in wallets

This is a good question. Do we want to use OpenID Federation for that?

Personally, I would leave this out to keep the first version as simple as possible. To me, trust towards the wallet or the wallet provider seems a high-assurance requirement. I believe that many use cases can live with non-trusted wallets.

If others feel like this is an important feature, please suggest the wording that should be included.

I agree, that's why I think it should be added to the "This profile does not apply to" section, so it's expliclty out of scope for now

spec/federation-profile.md

TimoGlastra · 2025-12-02T14:41:48Z

spec/federation-profile.md

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


Suggested change

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.

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

Good clarification. Perhaps also the latter Entity Configuration should be capitalized.

TimoGlastra · 2025-12-02T14:45:35Z

spec/federation-profile.md

+}
+```
+
+#### SD-JWT VC Credentials


This doesn't specify where to resolve the signing keys. I think we need to define a custom entity type with jwks field

Can we use jwt_vc_issuer (referring to 5.1 in https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/?

Why aren't we using cnf with kid for SD-JWT VC and kid for VCDM2 SD-JWT?

We already publish the JWKS, so then it is just a matter of mapping the kid to the JWK and matching that against the JWKS

We already publish the JWKS

I don't think we can reuse the already published JWKS, as you shouldn't reuse the Federation keys for non-federation operations. So we do need a new entity in the federation.

Why not it is a set

Because:

These Federation Entity Keys SHOULD NOT be used in other protocols. (Keys to be used in other protocols, such as OpenID Connect, are conveyed in the metadata elements for the protocol's Entity Type Identifiers, such as the metadata under the openid_provider and openid_relying_party Entity Type Identifiers.)

https://openid.net/specs/openid-federation-1_0.html#section-3.1-1.10.2

TimoGlastra · 2025-12-02T14:46:56Z

spec/federation-profile.md

+
+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


This doesn't define how to resolve the signing key. Can be the same as SD-JWT VC (since both use jwt signing). But we should mention that it specifically applies to jwt signed w3c creds

Why aren't we using cnf with kid for SD-JWT VC and kid for VCDM2 SD-JWT?

We already publish the JWKS, so then it is just a matter of mapping the kid to the JWK and matching that against the JWKS

TimoGlastra · 2025-12-02T14:49:12Z

spec/federation-profile.md

+
+#### Verifier Metadata Publication
+
+The Verifier MUST place verifier metadata into the Entity Configuration, in the `openid_credential_verifier` property.


OpenID4VP mentions that you MUST ignore the contents of the openid4vp request client_metadata, but one thing that loses is thst you can't use ephemeral keys anymore for response encryption. Do we want to allow for an exception for jwks for encryption?

Tbh i think this should be an issue in openid4vp

Agreed that this should be solved in OID4VP.

Opened an issue: openid/OpenID4VP#685

TimoGlastra · 2025-12-02T14:51:09Z

spec/federation-profile.md

+
+### 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.


Suggested change

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.

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. The verifier MUST verify that each credential is signed with a key in the 'credential_issuer' JWK set.

I'm kind of reluctant to put any MUST requirements on the Verifier. It is the Verifier's decision, based on their risk appetite, what to verify and validate. What we can say in a technical specification like this is what functionality the software must support. That is different from requiring actions from the users of the software.

I do agree that, in order to trust the credentials, the signing keys must be verified. I would just like to reword this in another way.

I very strongly disagree.

I think that a rabbit hole we should not cover in this profile. I think one of the most important things in a verifiable credential ecosystem is to describe the requirements for credential verification. That's where the security and trust comes from. I can't think of any reason why you wouldn't want to verify that the credential is actually signed by the issuer.

IMO if you don't want to verify this, you should still verify that credential is signed by the issuer, but you just don't care about whether you trust the credential issuer. But in my opinion we MUST ensure that the cryptographic verification is handled. What you do after that is up to you.

There's a difference in saying:

We haven't verified at all if this credential is signed by this issuer

We have verified that the credential is signed by this issuer but we don't know who this issuer is

We have verified that the credential is signed by this issuer and we know who this issuer is.

The minimum level we MUST verify IMO is 2. Not including 1. is non-negotiable IMO.

But curious to hear others' input on this

@nklomp @nanderstabel @JelleMillenaar @surfnet-niels

Just read the verification requirements for SD-JWT VC: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html#section-3.5

They're also very clear on the MUST and otherwise the SD-JWT must be rejected. I don't think we should go against this

I do agree with @TimoGlastra here. Signature validation should be a must!

TimoGlastra · 2025-12-02T14:53:06Z

spec/spec.md

-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]].**


Not sure we should use the term Agent, maybe just "implementation"?

Would you also want to remove the definition of Agent in the main spec? And the existing 11 references to it?

I rather have us explicitly use the term agent tbh. Especially with all the new people entering the scene and calling everything a wallet

samuelmr · 2025-12-16T10:51:37Z

@k00ij, @surfnet-niels, @muisit, @nklomp, @sanderPostma, @eklaver, @nanderstabel, @ubamrein, @lebedenko-ubique, @goIDmobility, @hacdias, @endimion – please review and comment if you want to influence the DIIP v5.

See rendered versions of spec.md and profile.md for easier reading.

samuelmr · 2025-12-18T06:40:54Z

The revised federation-profile.md now contains the requirement to include jwt_vc_issuer.jwks in the Entity Configuration and the requirement that the key with the kid of the credential is found in the jwks.

nklomp

Provided some comment.
Mainly arround mandating support in V5 and resolution/jwks

nklomp · 2025-12-18T18:07:42Z

spec/federation-profile.md

+
+**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.)


Any reason why we are exlcuding jwks uri?

I think also maybe we shouldn't call it jwt_vc_issuer? It doesn't seem very compatible for extension to other credential formats (while it may work for just W3C SD-JWT and SD-JWT VC)

@nklomp the idea is that if you want to include the keys in the Entity Configuration to be a part of the signed JWT, you include the keys, not a reference to a resource that can change any time.

@TimoGlastra, my idea was to mirror /.well-known/jwt-vc-issuer from https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html#name-jwt-vc-issuer-metadata instead of inventing a property of our own.

Yes but this is focussed on a single credential format. In our case we are potentially supporting multiple credential formats, not neccesarily JWT-bound. We can build on the jwt-vc-isuser, but just call it vc-issuer? No other changes needed I think?

Otherwise if we want to support W3C Data Integrity we have to come up with a new approach, just because it's named JWT VC Issuer.

nklomp · 2025-12-18T18:09:36Z

spec/federation-profile.md

+
+**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.**


Suggested change

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

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

Suggested change

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

**Requirement: The Wallet MUST use `openid_credential_issuer` metadata and ignore the issuer metadata published in the well-known location defined in OID4VCI.**

It is already a MUST to have the property. Phrasing it with an if leaves it, in my opinion, open to possible interpretations on what to do, if something is wrong with the metadata in the EC (but correct under the oid4vci well-known) and so on.

There may be credential issuers that are not DIIP compliant but have Entity Configurations. When a wallet encounters such a credential issuer, it should use the regular OID4VCI metadata.

nklomp · 2025-12-18T18:10:49Z

spec/federation-profile.md

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


Should we say something about the wallet being allowed to display values from the federation_entity level that is not in openid_credential_issuer?

Is there a clear mapping of, which property overwrites what property? E.g. organization_name and display_name is a bit of an arbitrary mapping without having looked into either of the RFCs "definition" of the properties. Why not use the either one of them?

@nklomp we're trying to say that a wallet is allowed to display values from the federation_entity level (federation_entity.organization_name), but the values in the openid_credential_issuer level take precedence (openid_credential_issuer.display.name).

@ubamrein does this also answer your question? (There is no clear mapping.)

nklomp · 2025-12-18T18:14:49Z

spec/federation-profile.md

+
+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


Why aren't we using cnf with kid for SD-JWT VC and kid for VCDM2 SD-JWT?

We already publish the JWKS, so then it is just a matter of mapping the kid to the JWK and matching that against the JWKS

nklomp · 2025-12-18T18:15:01Z

spec/federation-profile.md

+}
+```
+
+#### SD-JWT VC Credentials


Why aren't we using cnf with kid for SD-JWT VC and kid for VCDM2 SD-JWT?

We already publish the JWKS, so then it is just a matter of mapping the kid to the JWK and matching that against the JWKS

nklomp · 2025-12-18T18:18:12Z

spec/federation-profile.md

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


I think this is too open ended. If we want to support it we should make the authoritiy hints and subordinate statement mandatory

Why aren't we using cnf with kid for SD-JWT VC and kid for VCDM2 SD-JWT?
We already publish the JWKS

Do you mean that the JWKS is published in the Entity Configuration, or that it is published as SD-JWT metadata?

How does the verifier of a VCDM2 SD-JWT find the Entity Configuration of the Issuer?

I think this is too open ended. If we want to support it we should make the authoritiy hints and subordinate statement mandatory

I don't follow.

It should not be mandatory to make the distinction between the Issuer (https://university-of-utopia.example.edu) and the Credential Issuer (https://credentials.ministryofeducation.example.edu), but it should be possible to make this distinction.

Support for authority hints and subordinate statements in general is, of course, mandatory, since you can't implement OpenID Federation without them.

nklomp · 2025-12-18T18:19:43Z

spec/spec.md

-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]].**


I rather have us explicitly use the term agent tbh. Especially with all the new people entering the scene and calling everything a wallet

nklomp · 2025-12-18T18:20:30Z

spec/spec.md

+
+**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.**


SHOULD instead of MUST, hinting that this become a MUST in vnext

nklomp · 2025-12-18T18:20:37Z

spec/spec.md

+
+**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.**


SHOULD instead of MUST, hinting that this become a MUST in vnext

nklomp · 2025-12-18T18:20:48Z

spec/spec.md

+
+**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]].**


SHOULD instead of MUST, hinting that this become a MUST in vnext

ubamrein · 2025-12-19T10:30:36Z

spec/federation-profile.md

+        }
+      ],
+      "credential_issuer": "https://credential-issuer.example",
+      "authorization_endpoint": "https://credential-issuer.example/authorize",


Wouldn't it be reasonable to also put the authorization server's metadata into the EC? I think often it is hosted by the same entity as the credential issuer (as is hinted towards it here, by using the same domain), which would reduce the number of requests that need to be done.

Good suggestion, IMHO.

Perhaps we should first agree how we want to present the JWKS (#79 (comment)).

samuelmr · 2025-12-20T07:55:00Z

As agreed in Thursday's DIIP meetup, I created a new PR #84.

Let's continue the discussion there.

samuelmr · 2026-01-13T05:44:52Z

replaced with #84

samuelmr added 6 commits December 2, 2025 15:04

bumps versions of OID4VCI and OID4VP to 1.0, bumps SD-JWT VC from dra…

4d55a8d

…ft 08 to draft 13 and IETF Token Status List from draft 10 to draft 13

formatting changes based on markdown-lint

06594fd

bumped version

84a26e1

added federation profile

4516ec6

moved OpenID Federation to the main spec draft

bbdc15d

Added OpenID Federation Digital Credential Profile requirements

b9574d8

samuelmr requested review from TimoGlastra, eklaver, k00ij and nklomp as code owners December 2, 2025 14:31

samuelmr had a problem deploying to github-pages December 2, 2025 14:31 — with GitHub Actions Failure

TimoGlastra reviewed Dec 2, 2025

View reviewed changes

added the jwt_vc_issuer requirement and example, emphasized requirements

02bb442

samuelmr had a problem deploying to github-pages December 18, 2025 05:52 — with GitHub Actions Failure

added the requirement to check kid

f30adf4

samuelmr had a problem deploying to github-pages December 18, 2025 06:02 — with GitHub Actions Failure

nklomp requested changes Dec 18, 2025

View reviewed changes

ubamrein reviewed Dec 19, 2025

View reviewed changes

samuelmr added 2 commits December 20, 2025 08:28

The requirements regarding Trust Establishment are OPTIONAL in DIIP v5

823e216

The requirements regarding Trust Establishment are OPTIONAL in DIIP v5

6575c28

samuelmr had a problem deploying to github-pages December 20, 2025 06:29 — with GitHub Actions Failure

samuelmr temporarily deployed to github-pages December 20, 2025 06:36 — with GitHub Actions Inactive

samuelmr added 4 commits December 20, 2025 08:47

fixed links

0306d60

removed incorrect Issuer and Verifier references

98f860a

new publishing method doesn't need latest.html

e9ab8e7

removed draft from title

81d11ed

samuelmr temporarily deployed to github-pages December 20, 2025 06:53 — with GitHub Actions Inactive

samuelmr had a problem deploying to github-pages December 20, 2025 06:53 — with GitHub Actions Failure

samuelmr added 2 commits December 20, 2025 09:18

minor changes in Issuer capitalization

1c32830

minor changes based on discussions in FIDEScommunity#79

6aeadc2

samuelmr had a problem deploying to github-pages December 20, 2025 07:47 — with GitHub Actions Failure

samuelmr temporarily deployed to github-pages December 20, 2025 07:48 — with GitHub Actions Inactive

TimoGlastra mentioned this pull request Jan 5, 2026

DIIP v5 #84

Open

samuelmr closed this Jan 13, 2026

	- Credential verifiers publishing verifier metadata
	- Credential verifiers publishing OID4VP metadata


		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.


		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


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


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

	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.
	Requirement: The Wallet MUST use `openid_credential_issuer` metadata 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.


		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.


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

V5 draft #79

V5 draft #79

Uh oh!

Conversation

samuelmr commented Dec 2, 2025

Uh oh!

samuelmr commented Dec 2, 2025

Uh oh!

TimoGlastra left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TimoGlastra Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimoGlastra Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimoGlastra Dec 2, 2025 •

edited

Loading

TimoGlastra Dec 19, 2025 •

edited

Loading