Security considerations for client_metadata parameters by dpostnikov · Pull Request #735 · openid/OpenID4VP

dpostnikov · 2026-04-27T23:39:48Z

resolves #670

Solves #670

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>

jogu · 2026-05-07T15:51:44Z

+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 certificate can be trusted, whereas a client name from the `client_metadata` parameter cannot.
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


I think we have to be careful not to conflict with this text:

"It is recommended" probably needs to be reworded, and 'Ecosystems' we used 'profiles' in the other text.

@jogu What specifically is the problem with the "it is recommended" text? Just that it reads as a normative statement?

And what about something like this:

Suggested change

Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 certificate can be trusted, whereas a client name from the `client_metadata` parameter cannot.

It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key.

Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

Ecosystems can define other ecosystem-specific trusted data sources in a profile as long as they conduct a proper trust evaluation.

@jogu where do you think it conflicts? Is it the example of the public key and should we be more specific that it is about specific, ephemeral public keys as described in the section?

In the spec I also often notice we use "ecosystems or profiles" instead of the one or the other. Maybe that applies here as well.

@jogu Would be great to have some more detail on this.

I think my concern was in the conflict between

It is recommended (for Wallet implementers) to use client_metadata parameters...

and

Other metadata parameters MUST be ignored unless a profile <...>'

If the recommendation is scoped to profiles that's better. But maybe something like:

Profiles MAY define additional client_metadata parameters for client-supplied parameters that can be used untrusted, for example, a public key.

(Pretty sure that can be improved upon)

paulbastian · 2026-06-04T15:09:10Z

@fkj to re-review
@jogu please re-review
@c2bo @javereec to also add reviews

fkj · 2026-06-11T09:59:35Z

+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 certificate can be trusted, whereas a client name from the `client_metadata` parameter cannot.
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


@jogu What specifically is the problem with the "it is recommended" text? Just that it reads as a normative statement?

And what about something like this:

Suggested change

Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 certificate can be trusted, whereas a client name from the `client_metadata` parameter cannot.

It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key.

Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

Ecosystems can define other ecosystem-specific trusted data sources in a profile as long as they conduct a proper trust evaluation.

jogu · 2026-07-06T11:45:25Z

+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 certificate can be trusted, whereas a client name from the `client_metadata` parameter cannot.
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


I think my concern was in the conflict between

It is recommended (for Wallet implementers) to use client_metadata parameters...

and

Other metadata parameters MUST be ignored unless a profile <...>'

If the recommendation is scoped to profiles that's better. But maybe something like:

Profiles MAY define additional client_metadata parameters for client-supplied parameters that can be used untrusted, for example, a public key.

(Pretty sure that can be improved upon)

brentzundel · 2026-07-06T19:23:01Z

@dpostnikov can you respond to reviews here before the WG calls this week?

brentzundel · 2026-07-16T15:39:01Z

@dpostnikov we need your response to the comments and requests for changes

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com> Co-authored-by: Joseph Heenan <joseph@heenan.me.uk> Co-authored-by: Lukasz Jaromin <lukasz.jaromin@raidiam.com>

dpostnikov

Apply suggestions from code review
Co-authored-by: Frederik Krogsdal Jacobsen fkj@users.noreply.github.com
Co-authored-by: Joseph Heenan joseph@heenan.me.uk
Co-authored-by: Lukasz Jaromin lukasz.jaromin@raidiam.com

fkj · 2026-08-05T11:51:05Z

+
+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 


This uses a "recommended" which we should probably either avoid or capitalize.

Also, the example should be a new sentence.

Applying Frederik's suggestion, plus also resolving my currently unresolved comment #735 (comment)

Suggested change

It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.

Profiles of this specification MAY define additional `client_metadata` parameters, as described in (#new_parameters). It is RECOMMENDED that such parameters are limited to client-supplied values that can safely be used without being trusted. One example of such a value is a public key used to encrypt the Authorization Response.

fkj · 2026-08-05T11:52:54Z


+## Source of Verifier Metadata
+
+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 


This uses a "should" which we should avoid here I think.
It's not really clear what the second sentence actually is intended to mean: "should" it determine or does it determine?

This addresses both your points I think, as well as cleaning up a bit of terminology and simplifying wording:

Suggested change

Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display.

Wallet implementers need to choose a source of Verifier metadata they can trust within their own ecosystem or implementation, including determining whether metadata is safe to use or display to an End-User. For example, a Verifier name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be suitable to display to an End-User, whereas a Verifier name from the `client_metadata` parameter is not suitable to display.

fkj · 2026-08-05T11:53:07Z

+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


can -> MAY?

Suggestion that resolves that and my own ecosystem vs profiles point.

Suggested change

Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

Wallets MAY use other ecosystem-specific trusted sources of Verifier metadata, provided the Wallet is able to establish trust in those sources. As described in (#new_parameters), authoritative data obtained from such sources takes precedence over the values passed in the `client_metadata` parameter.

jogu · 2026-08-10T10:06:47Z


+## Source of Verifier Metadata
+
+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 


This addresses both your points I think, as well as cleaning up a bit of terminology and simplifying wording:

Suggested change

Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display.

Wallet implementers need to choose a source of Verifier metadata they can trust within their own ecosystem or implementation, including determining whether metadata is safe to use or display to an End-User. For example, a Verifier name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be suitable to display to an End-User, whereas a Verifier name from the `client_metadata` parameter is not suitable to display.

jogu · 2026-08-10T10:08:29Z


+## Source of Verifier Metadata
+
+Wallet implementers need to choose a sources of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 


Repeating my above suggestion as it needs applied here too:

Suggested change

Wallet implementers need to choose a sources of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display.

Wallet implementers need to choose a source of Verifier metadata they can trust within their own ecosystem or implementation, including determining whether metadata is safe to use or display to an End-User. For example, a Verifier name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be suitable to display to an End-User, whereas a Verifier name from the `client_metadata` parameter is not suitable to display.

jogu · 2026-08-10T10:20:20Z

+
+Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 


Applying Frederik's suggestion, plus also resolving my currently unresolved comment #735 (comment)

Suggested change

It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.

Profiles of this specification MAY define additional `client_metadata` parameters, as described in (#new_parameters). It is RECOMMENDED that such parameters are limited to client-supplied values that can safely be used without being trusted. One example of such a value is a public key used to encrypt the Authorization Response.

jogu · 2026-08-10T10:21:20Z

+
+Wallet implementers need to choose a sources of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display. 
+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 


Repeating my above suggestion as it needs applied here too:

Suggested change

It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.

Profiles of this specification MAY define additional `client_metadata` parameters, as described in (#new_parameters). It is RECOMMENDED that such parameters are limited to client-supplied values that can safely be used without being trusted. One example of such a value is a public key used to encrypt the Authorization Response.

jogu · 2026-08-10T10:23:29Z

+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


Suggestion that resolves that and my own ecosystem vs profiles point.

Suggested change

Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

Wallets MAY use other ecosystem-specific trusted sources of Verifier metadata, provided the Wallet is able to establish trust in those sources. As described in (#new_parameters), authoritative data obtained from such sources takes precedence over the values passed in the `client_metadata` parameter.

jogu · 2026-08-10T10:25:50Z

+* `x509_san_dns`: When the Client Identifier Prefix is `x509_san_dns`, the original Client Identifier (the part after the `x509_san_dns:` prefix) MUST be a DNS name and match a `dNSName` Subject Alternative Name (SAN) [@!RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header [@!RFC7515] of the signed request object. The Wallet MUST validate the signature and the trust chain of the X.509 certificate. The following requirement applies unless the interaction is using the DC API as defined in (#dc_api): 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`.

-* `x509_hash`: When the Client Identifier Prefix is `x509_hash`, the original Client Identifier (the part without the `x509_hash:` prefix) MUST be a hash and match the hash of the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header parameter [@!RFC7515] of the signed request object. The value of `x509_hash` is the base64url-encoded value of the SHA-256 hash of the DER-encoded X.509 certificate. The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate. All Verifier metadata other than the public key MUST be obtained from the `client_metadata` parameter. Example Client Identifier: `x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk`
+* `x509_hash`: When the Client Identifier Prefix is `x509_hash`, the original Client Identifier (the part without the `x509_hash:` prefix) MUST be a hash and match the hash of the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header parameter [@!RFC7515] of the signed request object. The value of `x509_hash` is the base64url-encoded value of the SHA-256 hash of the DER-encoded X.509 certificate. The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate. Example Client Identifier: `x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk`


Add the missing fullstop (the 1.0 change already added this):

Suggested change

* `x509_hash`: When the Client Identifier Prefix is `x509_hash`, the original Client Identifier (the part without the `x509_hash:` prefix) MUST be a hash and match the hash of the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header parameter [@!RFC7515] of the signed request object. The value of `x509_hash` is the base64url-encoded value of the SHA-256 hash of the DER-encoded X.509 certificate. The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate. Example Client Identifier: `x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk`

* `x509_hash`: When the Client Identifier Prefix is `x509_hash`, the original Client Identifier (the part without the `x509_hash:` prefix) MUST be a hash and match the hash of the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header parameter [@!RFC7515] of the signed request object. The value of `x509_hash` is the base64url-encoded value of the SHA-256 hash of the DER-encoded X.509 certificate. The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate. Example Client Identifier: `x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk`.

jogu · 2026-08-10T10:50:52Z

+
+It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response. 
+
+Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation. 


Repeating 1.0 suggestion from above:

Suggested change

Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

Wallets MAY use other ecosystem-specific trusted sources of Verifier metadata, provided the Wallet is able to establish trust in those sources. As described in (#new_parameters), authoritative data obtained from such sources takes precedence over the values passed in the `client_metadata` parameter.

Security considerations for client_metadata parameters

b3d6380

Solves #670

dpostnikov requested review from Sakurann, jogu and paulbastian April 28, 2026 19:37

dpostnikov mentioned this pull request Apr 28, 2026

Retrieving all client metadata from client_metadata parameter seems too restrictive #670

Open

brentzundel approved these changes May 7, 2026

View reviewed changes

fkj requested changes May 7, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md Outdated

Update 1.1/openid-4-verifiable-presentations-1_1.md

533347b

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>

jogu requested changes May 7, 2026

View reviewed changes

fkj requested review from c2bo and javereec June 4, 2026 15:13

fkj reviewed Jun 11, 2026

View reviewed changes

fkj requested a review from jogu June 15, 2026 19:33

jogu requested changes Jul 6, 2026

View reviewed changes

jogu reviewed Jul 7, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md Outdated

Apply suggestions from code review

1dddd65

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com> Co-authored-by: Joseph Heenan <joseph@heenan.me.uk> Co-authored-by: Lukasz Jaromin <lukasz.jaromin@raidiam.com>

dpostnikov commented Aug 5, 2026

View reviewed changes

dpostnikov requested review from fkj, jogu and lj-raidiam August 5, 2026 06:26

dpostnikov added 2 commits August 5, 2026 16:30

Merge branch 'main' into dpostnikov-patch-3

d0d12c4

Apply the same changes to 1.0 errata as 1.1

4df3abc

dpostnikov requested a review from brentzundel August 5, 2026 07:40

fkj reviewed Aug 5, 2026

View reviewed changes

jogu reviewed Aug 10, 2026

View reviewed changes


		Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display.

		It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.

	It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.
	Profiles of this specification MAY define additional `client_metadata` parameters, as described in (#new_parameters). It is RECOMMENDED that such parameters are limited to client-supplied values that can safely be used without being trusted. One example of such a value is a public key used to encrypt the Authorization Response.


		## Source of Verifier Metadata

		Wallet implementers need to choose a source of client metadata they can trust within their own ecosystem or implementation. This should determine whether it is safe to use or display to a User. For example, a client name obtained from an X.509 leaf certificate that chains to a trust anchor the Wallet trusts may be appropriate to be displayed to an End-User, whereas a client name from the `client_metadata` parameter is not suitable to display.


		It is recommended to use `client_metadata` parameters only for client-supplied parameters that can be used untrusted, for example, a public key used to encrypt the response.

		Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.

	Ecosystems can use other ecosystem-specific trusted data sources as long as they conduct a proper trust evaluation.
	Wallets MAY use other ecosystem-specific trusted sources of Verifier metadata, provided the Wallet is able to establish trust in those sources. As described in (#new_parameters), authoritative data obtained from such sources takes precedence over the values passed in the `client_metadata` parameter.

Uh oh!

Conversation

dpostnikov commented Apr 27, 2026 • edited by Sakurann Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

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!

paulbastian commented Jun 4, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

brentzundel commented Jul 6, 2026

Uh oh!

Uh oh!

brentzundel commented Jul 16, 2026

Uh oh!

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

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

dpostnikov commented Apr 27, 2026 •

edited by Sakurann

Loading