Key resolution options: require x509_hash, remove web based key resolution #178

c2bo · 2025-03-17T08:23:28Z

Closes #43
closes #102
closes #35

openid4vc-high-assurance-interoperability-profile-1_0.md

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

openid4vc-high-assurance-interoperability-profile-1_0.md

jogu · 2025-05-02T10:41:55Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+This profile supports one mandatory way to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, x.509 certificates. This MUST be supported by all entities (Issuer, Wallet, Verifier):

-* Web-based key resolution: The key used to validate the Issuer’s signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.
 * x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the `x5c` JOSE header. In this case, the `iss` value MUST be an URL with a FQDN matching a `dNSName` Subject Alternative Name (SAN) [@!RFC5280] entry in the leaf certificate.


I think we need to see something about 'MUST validate against a root certificate but how you get the root certificate is out of scope' ?

We have this in the "out of scope" descrptiont:

Trust Management refers to authorization of an Issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials. Although X.509 PKI is extensively utilized in this profile, the methods for establishing trust or obtaining root certificates are out of the scope of this specification.

I think that is enough, maybe it would be worth it to link there?

Ah, thanks. That's probably fine then.

jogu · 2025-05-02T10:47:26Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+Support for web-based key resolution is RECOMMENDED:
+
+* Web-based key resolution: The key used to validate the Issuer’s signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.


I'm not 100% sure I understand how this works. It seems to conflict with the requirement to support x5c.

I suspect the text referred to has been moved to section 3.5 ( https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-08.html#section-3.5 ) but also I think it's been renamed or something as I'm not clear which method in that section needs to be used.

I'm also not sure how this works, and if it's required to support X5C why support this other option, since you can't rely on it? Also since the Status List MUST use x5c, you then get like this weird combination of using web based key resolution vs X509 based.

Co-authored-by: Joseph Heenan <joseph@authlete.com> Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

awoie

Just flagging that mandating x509_hash as the only option for HAIP could introduce challenges for RP certificate rotation, particularly if the identifier is intended to serve as a long-term reference for the RP or is referenced by external entities or systems.

For example, this could impact trusted lists maintained by EU Member States, such as those involving registration or access certificates.

@cre8 What do you think? I would expect RP signer certificates to be rotated every 1–3 years, depending on compliance requirements. In such cases, all references would need to be updated, introducing overhead and increasing the risk of inconsistencies or broken links.

This is because the RP's identifier would effectively change with each certificate rotation.

charsleysa · 2025-07-03T23:23:19Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 ## Issuer identification and key resolution to validate an issued Credential {#issuer-key-resolution}

-This profile supports two ways to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, the web PKI-based key resolution and the x.509 certificates.
+This profile supports one mandatory way to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, x.509 certificates. This MUST be supported by all entities (Issuer, Wallet, Verifier):


This MUST be supported by all entities (Issuer, Wallet, Verifier):

Does this mean that existing issuers utilizing web-based key resolution are no longer HAIP compatible? I disgree that web-based key resolution should be considered HAIP incompatible.

My current interpretation would be: Every entity has to support the x.509 based key resolution / trust establishment for sd-jwt vc to be HAIP compatible. The different entities might also support other ways like web-based key resolution, but for interop we have to mandate support for at least one mechanism everyone implements.

charsleysa · 2025-07-04T00:06:16Z

With x509_hash being the chosen client identifier prefix, how is redirect_uri / response_uri trust established?

With x509_san_dns it was clear that the FQDN of both the client identifier and the redirect_uri / response_uri needed to match (unless there was established trust). This does not exist for x509_hash.

If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value. If not, the FQDN of the redirect_uri value MUST match the Client Identifier without the prefix x509_san_dns:. Example Client Identifier: x509_san_dns:client.example.org.

openid4vc-high-assurance-interoperability-profile-1_0.md

Sakurann · 2025-07-17T15:27:06Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 * Authorization Request MUST be sent using the `request_uri` parameter as defined in JWT-Secured Authorization Request (JAR) [@!RFC9101].
-* The Client Identifier Scheme as introduced in Section 5.10 of [@!OIDF.OID4VP] MUST be either `x509_san_dns` or `verifier_attestation`. The Wallet MUST support both. The Verifier MUST support at least one.
-* To obtain the issuer's public key for verification, verifiers MUST support Web-based key resolution, as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.
+* For Client Identifier Schemes as introduced in Section 5.9 of [@!OIDF.OID4VP], `x509_hash` MUST be supported by the Wallet and used by the Verifier.


Suggested change

* For Client Identifier Schemes as introduced in Section 5.9 of [@!OIDF.OID4VP], `x509_hash` MUST be supported by the Wallet and used by the Verifier.

* For Client Identifier Prefixes as introduced in Section 5.9 of [@!OIDF.OID4VP], `x509_hash` MUST be supported by the Wallet and used by the Verifier.

Sakurann · 2025-07-17T15:31:10Z

WG discussion. maybe mention that client id prefix x509_hash changes when the x509 cert changes, so the same client may have multiple client ids

Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com>

Co-authored-by: Joseph Heenan <joseph@authlete.com>

openid4vc-high-assurance-interoperability-profile-1_0.md

Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com>

openid4vc-high-assurance-interoperability-profile-1_0.md

jogu · 2025-07-22T17:30:03Z

I believe this closes #102 as well, so I've added that to the first comment.

Co-authored-by: Joseph Heenan <joseph@authlete.com>

x5c is required as per #178 This leaves it unsaid what iss is actually set to. I raised #215 in case we need to say something about that but think the scope of this PR should just be removing the text that is now inconsistent with other parts of HAIP.

cre8 · 2025-07-29T15:25:51Z

Just flagging that mandating x509_hash as the only option for HAIP could introduce challenges for RP certificate rotation, particularly if the identifier is intended to serve as a long-term reference for the RP or is referenced by external entities or systems.

For example, this could impact trusted lists maintained by EU Member States, such as those involving registration or access certificates.

@cre8 What do you think? I would expect RP signer certificates to be rotated every 1–3 years, depending on compliance requirements. In such cases, all references would need to be updated, introducing overhead and increasing the risk of inconsistencies or broken links.

This is because the RP's identifier would effectively change with each certificate rotation.

A bit late to the party but:

lifetime of the RP signer certificates (known as access certificates) will be defined by the policies. Based on the fact that these certificates can be renewed automatically, the lifetime will not be longer than two years (maybe just some months?)

c2bo added 3 commits March 16, 2025 18:21

define key resolution mechanisms

9b963fc

document history

7333822

fix wording and remove redudant statement

bab4105

c2bo requested review from Sakurann, awoie, bc-pi, jogu, martijnharing, paulbastian and tlodderstedt March 17, 2025 08:23

peppelinux mentioned this pull request Mar 18, 2025

Deprecation and removal of x509_san_uri italia/eudi-wallet-it-python#390

Closed

Sakurann approved these changes Mar 18, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Apply suggestions from Kristina's review

03b7880

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

cre8 approved these changes Apr 29, 2025

View reviewed changes

jogu requested changes May 2, 2025

View reviewed changes

Apply suggestions from Joseph's review

a141373

Co-authored-by: Joseph Heenan <joseph@authlete.com> Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

awoie reviewed Jul 3, 2025

View reviewed changes

remove web-based key resolution option

5b64892

charsleysa reviewed Jul 3, 2025

View reviewed changes

c2bo commented Jul 9, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

bc-pi reviewed Jul 9, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

jogu mentioned this pull request Jul 10, 2025

mandate certain accepted_issuers type in HAIP for both mdoc and sd-jwt vc #160

Closed

Sakurann reviewed Jul 17, 2025

View reviewed changes

Sakurann requested review from TimoGlastra, awoie, bc-pi, charsleysa and jogu July 17, 2025 15:31

c2bo and others added 4 commits July 17, 2025 17:45

Merge branch 'main' into 43-key-resolution

d99fbf9

Apply suggestions from Brian's review

ef97b57

Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com>

Apply suggestions from Joseph's review

cde5d86

Co-authored-by: Joseph Heenan <joseph@authlete.com>

remove list

f6b33fa

bc-pi reviewed Jul 17, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Apply suggestions from Brian's review

2d62177

Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com>

jogu approved these changes Jul 22, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Show resolved Hide resolved

jogu changed the title ~~Key resolution options~~ Key resolution options: require x509_hash, remove web based key resolution Jul 22, 2025

jogu mentioned this pull request Jul 22, 2025

Issuers/Verifiers choice for either x5c or jwt-vc issuer metadata is not clear #102

Closed

Sakurann and others added 2 commits July 22, 2025 21:09

Merge branch 'main' into 43-key-resolution

0ee5ae6

Apply suggestions from joseph's review

a44ec78

Co-authored-by: Joseph Heenan <joseph@authlete.com>

Sakurann merged commit 58ec081 into main Jul 22, 2025
2 checks passed

jogu mentioned this pull request Jul 23, 2025

Remove now incorrect sentence about iss in SD-JWT VC #216

Merged

mickrau mentioned this pull request Aug 21, 2025

reasons for using x509_hash instead of x509_san_dns? #243

Closed

		Support for web-based key resolution is RECOMMENDED:

		* Web-based key resolution: The key used to validate the Issuer’s signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.

	* For Client Identifier Schemes as introduced in Section 5.9 of [@!OIDF.OID4VP], `x509_hash` MUST be supported by the Wallet and used by the Verifier.
	* For Client Identifier Prefixes as introduced in Section 5.9 of [@!OIDF.OID4VP], `x509_hash` MUST be supported by the Wallet and used by the Verifier.

Key resolution options: require x509_hash, remove web based key resolution #178

Key resolution options: require x509_hash, remove web based key resolution #178

Uh oh!

Conversation

c2bo commented Mar 17, 2025 • edited by Sakurann Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jogu May 2, 2025

Choose a reason for hiding this comment

Uh oh!

c2bo Jul 3, 2025

Choose a reason for hiding this comment

Uh oh!

jogu Jul 3, 2025

Choose a reason for hiding this comment

Uh oh!

jogu May 2, 2025

Choose a reason for hiding this comment

Uh oh!

TimoGlastra May 13, 2025

Choose a reason for hiding this comment

Uh oh!

awoie left a comment • 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!

charsleysa Jul 3, 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!

c2bo Jul 9, 2025

Choose a reason for hiding this comment

Uh oh!

charsleysa commented Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Sakurann Jul 17, 2025

Choose a reason for hiding this comment

Uh oh!

Sakurann commented Jul 17, 2025

Uh oh!

Uh oh!

Uh oh!

jogu commented Jul 22, 2025

Uh oh!

Uh oh!

cre8 commented Jul 29, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

c2bo commented Mar 17, 2025 •

edited by Sakurann

Loading

awoie left a comment •

edited

Loading

charsleysa Jul 3, 2025 •

edited

Loading

charsleysa commented Jul 4, 2025 •

edited

Loading