non-ASCII/non-url safe characters characters in nonce/state/etc

[jogu]

I feel like we should probably take a position on the use of non-ASCII, and possibly even non-URL-safe characters, in state & nonce - at a minimum recommending that only URL safe characters are used.

state is already limited to ASCII by https://www.rfc-editor.org/rfc/rfc6749#appendix-A however this is no similar limitation for nonce (OpenID Connect just defines it as a "a string".)

I think in practice most experienced OAuth2 practitioners tend to restrict state & nonce to the URL safe character set.

The guidance VP currently gives on creating nonce is:

(1) The Verifier selects a nonce value as fresh, cryptographically random number with sufficient entropy and associates it with the session.

Something like this would probably be better:

(1) The Verifier generates 16 fresh, cryptographically random bytes with sufficient entropy, associates it with the session and base64url encodes it for use in the nonce parameter.

The advantage of limiting the character set as that it makes implementations/interop easier, as common mistakes in handling character sets (e.g. using Latin1 instead of UTF-8) or incorrectly handling URL escaping/unescaping, have no practical effect.

In contrast if we didn't impose a limitation then the conformance tests probably need to test the full set of characters allowed by the specification, and this is likely to mean the tests are significantly more difficult for implementations to pass. e.g. just yesterday I saw a node.js implementation that was encoding a non-ASCII character in nonce into a JWS in something other than the required UTF-8 and it wasn't obvious why it was doing that or how to fix it, and I've seen characters like ';' or '&' cause issues when used in url queries.

(I'm not sure if there any other places - at least other than the credentials themselves - where non-URL-safe characters are likely to appear in OID4VP?)

[awoie]

+1, supporting this

[Sakurann]

the proposal to limit "the use of non-ASCII, and non-URL-safe characters, in state & nonce" makes sense.

I am just a little confused with the proposed text. non-ASCII and non-url safe characters should be handled separately? why limit to 16 bytes?

[adeinega]

It's always a good idea to stick / require the URL safe characters... just to prevent app-level firewalls from potentially blocking requests regardless where and how you're passing non-URL-characters (in the query string or in the body). As an example, take a look at https://help.salesforce.com/s/articleView?id=000382900&type=1.

[jogu]

I am just a little confused with the proposed text. non-ASCII and non-url safe characters should be handled separately?

Yes, if we have consensus to add some requirements these should be added in a different section in addition to the text I suggested.

why limit to 16 bytes?

This is the "reference design" section for direct_post (which just happened to be the only place the spec really says anything about the properties of a nonce currently), so it's not normative and doesn't limit to 16 bytes. The reason for suggesting a size there is to make the reference design a fuller design that people can just use as-is.

The reason for suggesting 16 is that this is likely more than sufficient (resulting in I think 22 characters after base64url encoding). nonce is only used for binding the credential to the session; if there's a need to pass information about the session that should be done in state. It matches/exceeds the recommendation of 128 bits tokens in https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.4.2.2

[paulbastian]

+1 for mandting URLsafe encoding of the nonce
I would not limit to 16, but give a recommendation to provide at least 16.