kb_jwt in JSON serialisation

[alenhorvat]

_Holder adds the key kbjwt at the top-level of the serialized JWS with a string value containing the Key Binding JWT as described in Section 5.10.

Once the JWS is signed, the key binding is ensured via the signature. The current proposal asks the user to sign 2x

1. signature is the "signature" of the payload and protected header
2. is the key binding JWT which actually proves the same

Should the kb_jwt be removed from the JSON serialised JWS?

[danielfett]

I'm not sure I understand your point. The first signature is the signature by the Issuer, the second one by the Holder. This is the same for all data formats. Who is 'user' in your case?

[alenhorvat]

User is the holder. When writing https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/326 I realised that the JSON serialised JWS is signed by the issuer and then holder adds extra information to the JSON serialised JWS without signing it.

What's the rationale behind the design? I expected that holder, when sharing the SD-JWT + disclosures signs the whole thing, but that's not the case.

[danielfett]

Please see See https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/277 and https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/291. The gist is: The attack is fuzzy, while at the same time signing over everything has a huge penalty on the size of the SD-JWT. I would be open to discussing including the hash of the SD-JWT and disclosures in the KB-JWT if we identify that there is a clear need for it.

[alenhorvat]

In our use cases we're not concerned about the size since information is always retrieved from the server or sent to the server directly. Simplest is to ask the wallet providers just to sign the whole thing and that's it.

But I agree, if there are cases where the size is critical, e.g., sharing the payload via redirects, optimisation can applied.

[paulbastian]

An argument that I see for linking the disclosures (probably as hash) into the payload of the KB-JWT is, that:

• a holder could later dispute that he actually released certain claims as disclosures
• a verifier could dispute that he actually received certain disclosures To me this is a little weird because right now the signature gives us non-repudiation while the disclosures are repudiable.

[bc-pi]

PR #344 removes the kb_jwt from the JSON serialization and so will address this issue once merged.

Issue #346 is to separately track adding an option for a hash of the SD-JWT and Disclosures in the KB-JWT.