Working with Selective Disclosure credentials

[jean-sol-patre]

Problem:

Hi, it is hard to work with credentials with distinct issuance and presentation steps, like SD-JWT and SD-CWT.

Those credentials are first issued by the Issuer (the MLS AS in our case) (and signed by him), then, a presentation step occurs where the true MlsCredential is going to be created and signed by the Holder (the MLS Client in our case). In the case of SD-CWT, we call the token created from the presentaiton step an SD-KBT.

But this SD-KBT cannot be generated in advance, when one creates the MlsClient because one lacks the presentation context. Those presentation step occur during the following events:

• creating a new group (identity of the creator)
• generating a new KeyPackage
• joining via external commit

The current issue with MlsClient API is that it does not allow to provide a SigningIdentity in those 3 methods. The credential has to be passed along during the client creation.

Solution:

The solution would be to be able to pass a SigningIdentity in those 3 aforementioned methods. This would require having a builder API, like what is proposed in #207. It would be up to the user of the library to either pass a signing_identity when building an MlsClient for a Basic credential or to only supply it later for an SD-CWT.

To do that one should also allow not tie a Ciphersuite to a SigningIdentity when creating a MlsClient as enforced here and instead have a standalone method for defining the ciphersuite of the MlsClient.

NB: I also thought about declaring a struct SdCwtCredential(Vec<u8>) which would accept an SD-CWT when creating the MlsClient and do the presentation step (turning it into an SD-KBT) by adding a method to the IdentityProvider trait but it would lack some context that is application specific (like which claims of your identity you want to disclose) and would tedious to pass in such a callback

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links:
  • SD-JWT in mimi-pseudonyms
  • SD-CWT in mimi-pseudonyms
  • in mimi-identity-arch
• Related Issues:
  • [1.x] Externalize KeyPackageStorage and update key package generation API #207
• Testing: It shouldn't as it's an API change. While prototyping I want to explore if we could come up with an API that would enforce supplying a SigningIdentity in case it hasn't been passed to the constructor ; turning this into a compile-time error rather than a runtime error.

Out of scope:

This is not a request for supporting SD-CWT or SD-JWT. It can come later (when a crate is available).
Also happy to contribute :D