Clarify that the vp_token is **URL Safe** Base64 encoded, rather than a Base 64 encoded

[samuelgoto]

I ran into this issue while parsing the response by reading the spec, so figured others would too.

From:

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-6.1

It says:

Each Verifiable Presentation MUST be represented as a JSON string (that is a Base64url encoded value)

Which is correct, but incomplete. I think it should say something like:

Each Verifiable Presentation MUST be represented as a JSON string (that is a [URL Safe] Base64url encoded value)

For implementers, that's the difference between decoding as:

// From https://stackoverflow.com/questions/28100601/decode-url-safe-base64-in-javascript-browser-side
atob(data.replace(/_/g, '/').replace(/-/g, '+'))

Rather than:

atob(data)

[jogu]

It says base64url (rather than base64) which by definition is url safe I think? Did I miss something?

[bc-pi]

Yeah, the definition is a bit awkward to track down but it does say "base64url" and in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-terminology it has

and the term "Base64url Encoding" defined by JSON Web Signature (JWS) [RFC7515]

which RFC7515 in turn says at https://datatracker.ietf.org/doc/html/rfc7515#section-2 :

Base64url Encoding
Base64 encoding using the URL- and filename-safe character set
defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
characters omitted (as permitted by Section 3.2) and without the
inclusion of any line breaks, whitespace, or other additional
characters. Note that the base64url encoding of the empty octet
sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)

[samuelgoto]

The text in this specific section seems worth clarifying, IMHO:

https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-6.1

Each Verifiable Presentation MUST be represented as a JSON string (that is a Base64url encoded value)

Maybe something like the following?

Each Verifiable Presentation MUST be represented as a JSON string (that is a URL Safe Base64url encoded value)

[c2bo]

Currently Terminology says

[...] the term "JOSE Header" and the term "Base64url Encoding" defined by JSON Web Signature (JWS) [[RFC7515] [...]

Should we go the route of sd-jwt and explicitly introduce

base64url denotes the URL-safe base64 encoding without padding defined in Section 2 of [[RFC7515].

in terminology?

I think that would make things easier for an implementer/reader.