Skip to content

Add text on untrusted input to 1.0 - #759

Merged
Sakurann merged 5 commits into
mainfrom
748-untrusted-input-1-0
Jul 30, 2026
Merged

Add text on untrusted input to 1.0#759
Sakurann merged 5 commits into
mainfrom
748-untrusted-input-1-0

Conversation

@c2bo

@c2bo c2bo commented Jul 13, 2026

Copy link
Copy Markdown
Member

Mirrors the changes of #748 for 1.0 errata.

@c2bo
c2bo requested review from Sakurann, awoie, fkj, jogu and paulbastian July 13, 2026 21:58
@martijnharing

Copy link
Copy Markdown
Contributor

Given this text, is the following an accurate interpretation?

In the following cases any wallet is mandated to abort processing if:

  • There is a credential query id field that contains the character ~
  • There is a nonce field that contains the character ±

If the wallet supports encrypted response, it is mandated to abort processing if:

  • There is an encrypted_response_enc_values_supported field that contains the character ±

If the wallet supports the authority key identifier, it is mandated to abort processing if:

  • There is an authority key identifier that's not valid base64url

If the wallet supports signed requests and the wallet supports the x5c header, it is mandated to abort processing if:

  • The x5c header contains an element that's not a X.509 certificate

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated
@fkj

fkj commented Jul 30, 2026

Copy link
Copy Markdown
Member

Given this text, is the following an accurate interpretation?

@martijnharing After thinking through this a bit more, I think the pedantic answer is no.

This says that a Wallet MUST do input validation, but the specific steps are only a SHOULD. So if you are a very pedantic Wallet, you probably could argue in the direction of doing "input validation" but not actually doing any of the things we consider to be input validation. I think that would be a case of malicious compliance that only hurts the Wallet itself.

Orthogonally, this proposed text also does not say that the Wallet MUST do anything specific if the validation fails. If you want to strengthen it, we could add some text like we have in other places: "The Wallet MUST abort processing and return an error if any input did not pass the validation." I guess the error should be an invalid_request.

paulbastian and others added 2 commits July 30, 2026 17:34
Co-authored-by: Lukasz Jaromin <lukasz.jaromin@raidiam.com>
@Sakurann

Copy link
Copy Markdown
Collaborator

wg discussion
if after the discussions following your question, you believe there is a change needed to the spec, @martijnharing please open an issue about wallet behavior when input validation fails. if spec text stays the current way, wallet is not forced to abort a request whose validation failed.

@Sakurann
Sakurann merged commit 88216a2 into main Jul 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants