Upgrade to SD-JWT v12 & API rework

[UMR1352]

Updated the code base to support SD-JWT version 12 and modified the API to make it simpler and more ergonomic.

Major changes

• SdObjectEncoder / SdObjectDecoder are not public anymore, and are only used internally.
• SdJwt can only be constructed by parsing a string or through the new SdJwtBuilder.
• Added SdJwtBuilder which has the same functionalities of SdObjectEncoder but:
  • SdObjectEncoder::conceal becomes SdJwtBuilder::make_concealable.
  • SdJwtBuilder::finish returns a whole and valid SdJwt instead of a plaintext object and disclosures.
• Added JwsSigner trait, to create a JWS from header & payload.
• Added SdJwtPresentationBuilder which wraps an SdJwt and provides methods to easily conceal disclosable claims and attaching a KeyBinding JWT (KB-JWT).
• Added KeyBindingJwtBuilder to simplify the creation of KB-JWTs.
• Added RequiredKeyBinding to model a proof of possession for a given key through JWT's ctf claim.

Fixes

• Multibase-base64Url encoding was mistakenly used instead of Base64Url.
• Multiple hashers (to compute disclosure's digests) were allowed but that goes against the spec.

[wulfraem]

According to spec about the _sd array: "The array MAY be empty in case the Issuer decided not to selectively disclose any of the claims at that level. However, it is RECOMMENDED to omit the _sd key in this case to save space."

Wanted to test this behavior, but ran into issues, when creating a SD-JWT without any concealable properties. The serialized object had two of the tilde characters directly following another, which should not be the case according to the ABNF (SD-JWT = JWT "~" *[DISCLOSURE "~"]). This broke the parsing a step, that comes afterwards in the example. Removing them by hand lead to another error when parsing the SD-JWT without disclosures.

[wulfraem]

According to spec about the _sd array entries: "The Issuer MUST hide the original order of the claims in the array. To ensure this, it is RECOMMENDED to shuffle the array of hashes, e.g., by sorting it alphanumerically or randomly, after potentially adding decoy digests as described in Section 5.2.5. The precise method does not matter as long as it does not depend on the original order of elements."

I think, currently the order depends on the order the properties are marked as concealable or decoys are added. The shuffling could be done via calling the builder functions in a random order and only adding one decoy at a time per level, but as the spec also lists sorting the hashes alphabetically, sorting them when adding or serializing might be a nice way to make sure that their order is "shuffled".

[wulfraem]

Couldn't find a definitive answer in the spec, but when an issuer uses the .require_key_binding to add the cnf with the ref to the holder, should the holder be able to create a presentation without key binding? Currently, our example does this, but it feels off. If adding the KB-JWT would not be required in this case someone could just strip off the KB-JWT and present the SD-JWT without it, e.g. if not in the possession of the key mentioned in the SD-JWT.

But then again, the spec shifts the responsibility for deciding whether the KB-JWT is required or entirely to the verifier, but imho it sounds weird to present a SD-JWT with cnf without a KB-JWT.

[wulfraem]

Could we fix the "erros" -> "errors" typo in the bug_report.yml when being at it as well? Don't think, we'll need an extra PR for this. :D

[wulfraem]

I guess, we'll have to update the CI for the Windows build. Does not seem to be a temporary thing. >.<

[UMR1352]

Thank you @wulfraem for being the best reviewer ever. Going through your comments RN.

[UMR1352]

According to spec about the _sd array: "The array MAY be empty in case the Issuer decided not to selectively disclose any of the claims at that level. However, it is RECOMMENDED to omit the _sd key in this case to save space."

Wanted to test this behavior, but ran into issues, when creating a SD-JWT without any concealable properties. The serialized object had two of the tilde characters directly following another, which should not be the case according to the ABNF (SD-JWT = JWT "~" *[DISCLOSURE "~"]). This broke the parsing a step, that comes afterwards in the example. Removing them by hand lead to another error when parsing the SD-JWT without disclosures.

I fixed this and added a test that makes sure an SD-JWT with 0 disclosure is properly serialized / deserialized even when a KB-JWT is present.