Hi Jacob,
this check is mainly important for the Holder to ensure the integrity of
the received SD-JWT. For the Verifier, there is not much to gain by
checking this (but it also doesn't hurt either).
However, we intended to keep the algorithms for the Holder and Verifier
similar and therefore decided to not make an exception for the Verifier
here. It also enforces good "hygiene" for the Holder to not send any
Disclosures that don't belong into the SD-JWT (for example, a Disclosure
that originates from a claim in a recursive data structure, but where
the parent claim is not disclosed to the Verifier). This can also help
to avoid privacy problems.
-Daniel
Am 20.10.23 um 10:58 schrieb Jacob Ward:
Hello all,
Please let me know if there's a better channel to ask questions and/or
raise issues with the SD-JWT spec.
Currently as part of verification of an SD-JWT the following is stated:
/Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that /
* /the Issuer-signed JWT is valid, i.e., it is signed by the Issuer
and the signature is valid, and/
* /*all Disclosures are correct, i.e., their digests are referenced
in the Issuer-signed JWT.*/
As highlighted I have a question about this second bullet point. Can I
ask why the Disclosures must be referenced in the Issuer-signed JWT
and not simply ignored if they do not exist in the JWT? There doesn't
appear to be a security benefit to simply halt and to not verify what
could otherwise be a valid SD-JWT, as the unbound Disclosures would
never be processed as part of the SD-JWT verification anyway.
Apologies if this is something that has previously been discussed.
Jacob Ward
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth