Add a Discovery Use Case for establishing trust between the issuer and the verifier by peppelinux · Pull Request #59 · openid/federation-wallet

peppelinux · 2026-07-20T13:20:25Z

This pull request introduces a new use case describing how Credential Verifiers establish trust in Credential Issuers using OpenID Federation. It clarifies the mapping of https issuer identifiers in Digital Credentials to Federation Entity Identifiers, outlines the process for Federation Entity Discovery and offline trust validation, and makes clear that these use cases are independently adoptable by trust frameworks. The change log is updated to reflect these additions and clarifications.

New Trust Discovery Use Case: Credential Verifiers Establishing Trust in Credential Issuers

Added a normative section specifying that when a Credential Verifier uses OpenID Federation, it must validate the Credential Issuer’s cryptographic key, identity, and issuance entitlement via Trust Marks or policy, using Federation Entity Discovery or offline Trust Chain validation.
Detailed the process for mapping https issuer identifiers in presented Credentials to Federation Entity Identifiers, and specified that only https URLs are in scope (DIDs and other bindings are out of scope).
Provided step-by-step instructions and an ASCII diagram for performing Federation Entity Discovery, Trust Chain construction, and Digital Credential validation.
Clarified that use cases for trust discovery are independent; a trust framework may require any subset, and requirements apply only when the use case is used.

Offline Flows and Editorial Updates

Updated the offline flows section to clarify that Credential Verifiers (or Wallet Instances) can use a Trust Chain included in a signed Digital Credential to establish trust without real-time Federation Entity Discovery.
Updated the change log to document the new use case, clarifications on issuer identifier mapping, Trust Chain validation, and scope exclusions.

@TimoGlastra ^

…d the verifier

samuelmr

Suggested some changes.

samuelmr · 2026-07-25T10:10:29Z

+
+When a Credential Verifier uses OpenID Federation to establish trust in the Credential Issuer of a presented Digital Credential, the Credential Verifier MUST validate that:
+
+1. the cryptographic key used to sign the Digital Credential is (or was, at the time of issuance) bound to that Credential Issuer;


Isn't this kind of an obvious requirement, and something that the verifier should do regardless of the trust establishment framework used?

Shouldn't this spec state how to verify the key binding using OpenID Federation?

Something along these lines:

the cryptographic key used to sign the Digital Credential is listed in the jwks property of the Credential Issuer's openid_credential_issuer metadata;

I would keep your language for 1 @peppelinux and then add something along the lines of " - specifically, the cryptographic key used to sign the Digital Credential is listed in the jwks property of the Credential Issuer's openid_credential_issuer metadata".

samuelmr · 2026-07-25T10:17:42Z

+When a Credential Verifier uses OpenID Federation to establish trust in the Credential Issuer of a presented Digital Credential, the Credential Verifier MUST validate that:
+
+1. the cryptographic key used to sign the Digital Credential is (or was, at the time of issuance) bound to that Credential Issuer;
+2. the Credential Issuer is the Entity it claims to be; and


Rather:

the Credential Issuer is a (direct or indirect) subordinate of a Federation Entity that the Credential Verifier trusts; and

If the OpenID Federation specification had a way of specifying the trust ecosystem (e.g., named trust chains), this specification should also require the Credential Verifier to check that the Credential Issuer exists in a trust chain related to the trust ecosystem...

Maybe something to consider in OpenID Federation 2.0...

@peppelinux How does one determine that "the Credential Issuer is the Entity it claims to be"? Actionable instructions are probably called for here.

samuelmr · 2026-07-25T10:30:19Z

+
+OpenID Federation Entity Identifiers MUST be `https` URLs, as defined in [@!OpenID.Federation].
+
+When this use case applies and the Credential Issuer is identified in the Digital Credential by an `https` URL (for example, the `iss` claim in an SD-JWT VC or JWT-secured Credential, or the `issuer` / `issuer.id` value in a W3C Verifiable Credential), that URL MUST be used as the Credential Issuer's Federation Entity Identifier. That Entity Identifier MUST equal the `credential_issuer` metadata value and the `iss`/`sub` pair of the Credential Issuer's Entity Configuration, as profiled in the OpenID Credential Issuer Metadata Parameters section of this specification.


If a W3C VC DM credential has an issuer.id of https://uni.edu.utopia.example (identifying the University of Utopia as the organization issuing the credential), and the Credential Issuer endpoint and the iss value of the credential is https://credentials.gov.utopia.example (identifying the technical service used to issue the credential), how should this specification be applied?

samuelmr · 2026-07-25T10:36:29Z

+
+When this use case applies and the Credential Issuer is identified in the Digital Credential by an `https` URL (for example, the `iss` claim in an SD-JWT VC or JWT-secured Credential, or the `issuer` / `issuer.id` value in a W3C Verifiable Credential), that URL MUST be used as the Credential Issuer's Federation Entity Identifier. That Entity Identifier MUST equal the `credential_issuer` metadata value and the `iss`/`sub` pair of the Credential Issuer's Entity Configuration, as profiled in the OpenID Credential Issuer Metadata Parameters section of this specification.
+
+Alternative issuer identifiers that are not `https` URLs (for example, DIDs), and format-specific bindings such as ISO mDOC X.509 certificate chains, are out of scope for this version of the specification.


This is an understandable but unfortunate restriction.

Just a note: there are lots of credential issuer registries using OpenID Federation with did:key as the Entity Identifier. See, e.g., https://github.com/digitalcredentials/dcc-known-registries/blob/main/known-did-registries.json.

I know that they are violating the current OpenID Federation specification.

We could try to adapt the specifications to support what is already implemented instead of forcing everyone to stop using DIDs...

The purpose of this specification is to define how Federation Wallets can use OpenID Federation 1.0 and the OpenID4VC specs together. Extensions could define how to use DIDs as Leaf Entities, but that is out of scope for this specification.

samuelmr · 2026-07-25T10:44:54Z

+
+Alternative issuer identifiers that are not `https` URLs (for example, DIDs), and format-specific bindings such as ISO mDOC X.509 certificate chains, are out of scope for this version of the specification.
+
+### Federation Entity Discovery and Credential Validation


This section seems to contain explanatory text rather than specifying behavior not specified elsewhere or setting specific requirements.

There already exists the requirement to check the key binding and trust chain membership. OpenID Federation main specification explains how to do those.

I suggest dropping this section from this specification and perhaps authoring a separate explainer or tutorial document for these kinds of explanations.

I would prefer to keep this text, as it provides clear guidance to implementers about what kinds of Issuer Identifiers are supported.

selfissued · 2026-08-15T17:41:56Z

+2. the Credential Issuer is the Entity it claims to be; and
+3. where required by the trust framework, the Credential Issuer is entitled to issue that Credential (for example, via Trust Marks or metadata policy evaluated over the Trust Chain).
+
+This use case applies only when OpenID Federation is the trust mechanism used for that verification. An `https` issuer identifier in a Digital Credential does not by itself imply that the Credential Issuer participates in an OpenID Federation; other key-resolution mechanisms (for example, those defined by SD-JWT VC) MAY apply outside this use case.


Suggested change

This use case applies only when OpenID Federation is the trust mechanism used for that verification. An `https` issuer identifier in a Digital Credential does not by itself imply that the Credential Issuer participates in an OpenID Federation; other key-resolution mechanisms (for example, those defined by SD-JWT VC) MAY apply outside this use case.

This use case applies only when OpenID Federation is the trust mechanism used for that verification. An `https` Issuer Identifier in a Digital Credential does not by itself imply that the Credential Issuer participates in an OpenID Federation; other key-resolution mechanisms (for example, those defined by SD-JWT VC) MAY apply outside this use case.

selfissued · 2026-08-15T17:42:35Z


 The process of trust establishment in federated environments is illustrated in this section through specific use cases involving Wallet Instances, Credential Issuers (CIs), and Credential Verifiers (CVs).

+These use cases are independent: a trust framework MAY require support for any subset of them. Normative requirements in a use case apply only when that use case is used for OpenID Federation trust establishment.


Suggested change

These use cases are independent: a trust framework MAY require support for any subset of them. Normative requirements in a use case apply only when that use case is used for OpenID Federation trust establishment.

These use cases are independent: a Trust Framework MAY require support for any subset of them. Normative requirements in a use case apply only when that use case is used for OpenID Federation trust establishment.

selfissued

Please apply my minor editorial suggestions.

Add a Discovery Use Case for establishing trust between the issuer an…

9974dba

…d the verifier

peppelinux requested review from samuelmr and selfissued July 20, 2026 13:20

peppelinux linked an issue Jul 20, 2026 that may be closed by this pull request

Add a Discovery Use Case for establishing trust between the issuer and the verifier #48

Open

peppelinux mentioned this pull request Jul 20, 2026

Add a Discovery Use Case for establishing trust between the issuer and the verifier #48

Open

peppelinux requested a review from rohe July 20, 2026 13:21

samuelmr suggested changes Jul 25, 2026

View reviewed changes

selfissued reviewed Aug 15, 2026

View reviewed changes

selfissued approved these changes Aug 15, 2026

View reviewed changes

selfissued requested review from nklomp and surfnet-niels August 15, 2026 18:00


		When a Credential Verifier uses OpenID Federation to establish trust in the Credential Issuer of a presented Digital Credential, the Credential Verifier MUST validate that:

		1. the cryptographic key used to sign the Digital Credential is (or was, at the time of issuance) bound to that Credential Issuer;


		OpenID Federation Entity Identifiers MUST be `https` URLs, as defined in [@!OpenID.Federation].

		When this use case applies and the Credential Issuer is identified in the Digital Credential by an `https` URL (for example, the `iss` claim in an SD-JWT VC or JWT-secured Credential, or the `issuer` / `issuer.id` value in a W3C Verifiable Credential), that URL MUST be used as the Credential Issuer's Federation Entity Identifier. That Entity Identifier MUST equal the `credential_issuer` metadata value and the `iss`/`sub` pair of the Credential Issuer's Entity Configuration, as profiled in the OpenID Credential Issuer Metadata Parameters section of this specification.


		When this use case applies and the Credential Issuer is identified in the Digital Credential by an `https` URL (for example, the `iss` claim in an SD-JWT VC or JWT-secured Credential, or the `issuer` / `issuer.id` value in a W3C Verifiable Credential), that URL MUST be used as the Credential Issuer's Federation Entity Identifier. That Entity Identifier MUST equal the `credential_issuer` metadata value and the `iss`/`sub` pair of the Credential Issuer's Entity Configuration, as profiled in the OpenID Credential Issuer Metadata Parameters section of this specification.

		Alternative issuer identifiers that are not `https` URLs (for example, DIDs), and format-specific bindings such as ISO mDOC X.509 certificate chains, are out of scope for this version of the specification.


		Alternative issuer identifiers that are not `https` URLs (for example, DIDs), and format-specific bindings such as ISO mDOC X.509 certificate chains, are out of scope for this version of the specification.

		### Federation Entity Discovery and Credential Validation

	This use case applies only when OpenID Federation is the trust mechanism used for that verification. An `https` issuer identifier in a Digital Credential does not by itself imply that the Credential Issuer participates in an OpenID Federation; other key-resolution mechanisms (for example, those defined by SD-JWT VC) MAY apply outside this use case.
	This use case applies only when OpenID Federation is the trust mechanism used for that verification. An `https` Issuer Identifier in a Digital Credential does not by itself imply that the Credential Issuer participates in an OpenID Federation; other key-resolution mechanisms (for example, those defined by SD-JWT VC) MAY apply outside this use case.


		The process of trust establishment in federated environments is illustrated in this section through specific use cases involving Wallet Instances, Credential Issuers (CIs), and Credential Verifiers (CVs).

		These use cases are independent: a trust framework MAY require support for any subset of them. Normative requirements in a use case apply only when that use case is used for OpenID Federation trust establishment.

Uh oh!

Conversation

peppelinux commented Jul 20, 2026

Uh oh!

samuelmr 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!

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!

selfissued left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants