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:37:36Z


 In case of using OpenID4VP over DC API, as defined in (#dc_api), it is at the discretion of the Wallet whether it validates the signature on the Request Object following the processing rules defined by a relevant Client Identifier Prefix. Factors that influence the Wallet's decision include, but are not limited to, the trust framework the Wallet supports, the specific policies defined by the Issuers or ecosystem, and profiles of this specification.

-* `redirect_uri`: This prefix value indicates that the original Client Identifier part (without the prefix `redirect_uri:`) is the Verifier's Redirect URI (or Response URI when Response Mode `direct_post` is used). The Verifier MAY omit the `redirect_uri` Authorization Request parameter (or `response_uri` when Response Mode `direct_post` is used). All Verifier metadata parameters MUST be passed using the `client_metadata` parameter defined in (#new_parameters). An example Client Identifier value is `redirect_uri:https://client.example.org/cb`. Requests using the `redirect_uri` Client Identifier Prefix cannot be signed because there is no method for the Wallet to obtain a trusted key for verification. Therefore, implementations requiring signed requests cannot use the `redirect_uri` Client Identifier Prefix.


I suggest we put at least this change into 1.0 errata too.

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)

jogu · 2026-05-07T15:54:59Z


+## Source of verifier metadata considerations
+
+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.


Maybe something more 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.

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 End-User. For example, a client name obtained from an X.509 certificate that was used to a signed request, or a client name obtained from OpenID Federation from a signed requested, can be trusted, whereas a client name from the `client_metadata` parameter cannot.

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

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

fkj · 2026-06-11T08:19:34Z

 MUST perform its own security checks on the returned Credentials and
 Presentations.

+## Source of verifier metadata considerations


Nit: match the style of the other headings in this section:

Suggested change

## Source of verifier metadata considerations

## Source of Verifier Metadata

fkj · 2026-06-11T09:23:53Z


+## Source of verifier metadata considerations
+
+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.


A competing suggestion to @jogu's:

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.

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

Updated version of this - I think the 'can be trusted' in the original sentence is a bit too strong:

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.

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

I think it'd be good to mention OpenID Federation as an example too, but that's not a hill I feel I need to die on.

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)

jogu · 2026-07-06T11:49:28Z


+## Source of verifier metadata considerations
+
+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.


Updated version of this - I think the 'can be trusted' in the original sentence is a bit too strong:

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.

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

I think it'd be good to mention OpenID Federation as an example too, but that's not a hill I feel I need to die on.

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

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

jogu · 2026-07-07T14:17:59Z

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


Probably need to clarify this - a public key used for signature verification probably can't be trusted:

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.

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.

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


		In case of using OpenID4VP over DC API, as defined in (#dc_api), it is at the discretion of the Wallet whether it validates the signature on the Request Object following the processing rules defined by a relevant Client Identifier Prefix. Factors that influence the Wallet's decision include, but are not limited to, the trust framework the Wallet supports, the specific policies defined by the Issuers or ecosystem, and profiles of this specification.

		* `redirect_uri`: This prefix value indicates that the original Client Identifier part (without the prefix `redirect_uri:`) is the Verifier's Redirect URI (or Response URI when Response Mode `direct_post` is used). The Verifier MAY omit the `redirect_uri` Authorization Request parameter (or `response_uri` when Response Mode `direct_post` is used). All Verifier metadata parameters MUST be passed using the `client_metadata` parameter defined in (#new_parameters). An example Client Identifier value is `redirect_uri:https://client.example.org/cb`. Requests using the `redirect_uri` Client Identifier Prefix cannot be signed because there is no method for the Wallet to obtain a trusted key for verification. Therefore, implementations requiring signed requests cannot use the `redirect_uri` Client Identifier Prefix.


		## Source of verifier metadata considerations

		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.

	## Source of verifier metadata considerations
	## 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 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.

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!

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!

jogu May 7, 2026 • 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!

paulbastian commented Jun 4, 2026

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!

brentzundel commented Jul 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

dpostnikov commented Apr 27, 2026 •

edited by Sakurann

Loading

jogu May 7, 2026 •

edited

Loading