Unable to construct SD-JWT payload from disclosures without using hashing

[TimoGlastra]

To construct the 'pretty' payload of an SD-JWT, meaning the payload with the actual values rather than the hashes in the _sd field, you currently need to use a hashing algorithm to construct this payload.

One of the nice things about JWTs is that you can see the payload without having to verify it or use any hashing algorithms. The same is true for W3C credentials, where you can see the payload, and only start hashing/canonicalizing when you want to verify the signature.

Currently this makes it harder to separate different parts of processing an SD-JWT (the verification part which requires crypto, and the handling the content part, which often doesn't require crypto), and it either requires storing a copy of the SD-JWT in a way that doesn't require the hashing to construct the payload, or re-constructing the actual payload using hashing each time.

As this is more of an implementation detail, I think this may be a fair trade-off for this specification, but something I'm curious about if it has come up in discussions around this specification.

[danielfett]

This was a conscious design decision, as it forces verifiers to actually check the hashes before proceeding with the processing of the payload. A common mistake is to process the unverified payload instead of verifying it first; we can avoid that with this construction.

The algorithm for verification defined in the spec is supposed to run before any application logic that needs access to the full payload. So the idea is to verify/process the presented SD-JWT and only then pass the payload on to the application.

[TimoGlastra]

Okay that makes sense, thank you!