Interested in a meaningful contribution?

[Alexander Shcherbakov]

We've been working on a technology called DIDComm. It makes heavy use of JWKs, JWEs, and JWSs. It's being done in FOSS in conjunction with the Decentralized Identity Foundation, Trust Over IP Foundation, and Linux Foundation. Eventually the spec that we're trying to implement is going to IETF.

After studying various Java libs for JOSE, we have concluded that JOSE implementation from Nimbus-JOSE is closest to what we'd like to start from. But we need some new features:

• ECDH-1PU support (see ECDH-1PU draft)
• JSON serialization for JWS and JWE and multi-recipient support
• AEAD_XCHACHA20_POLY1305 (XC20P) support for content encryption (see Chacha draft)

We could just pull some code out of your excellent library and do our own independent thing, but we're wondering if you'd like a meaningful contribution of the features I listed above.

We'd do the work; we're not trying to find someone else to do the coding for us.

But before we start that contribution, we would like to know if it makes sense for you, and what are the chances that our PRs with all the features listed above will be accepted from the contributed features point of view.

[Vladimir Dzhuvinov]

Hi Alex,

This lib was initially conceived to address our need for clean JWT, OAuth 2.0 and OIDC support in Java about ten years ago and this still continues to be our main use case. But I do know that because of the open source nature of the lib it is also put to other uses and that is fine, because this resulting in a lot of useful feedback and quality changes. Few of our OSS projects have been that successful.

We (connect2id) have had some interest in Neil’s draft (ecdh-1pu) for quite some time since he presented it at a conf. It is a very sweet algorithm with properties not available in any other of the existing standard JWAs.

I’m not familiar with the draft-amringer-jose-chacha-02. It seems to have expired but that on itself is not a criteria for not having it if people find it useful, plus I know that it’s not always easy to get traction for spec completion at the IETF. If another variant gets adopted that’s not an issue, since the lib allows for different implementations of a JOSE algorithm.

So implementations for those two specs are certainly welcome. What matters is keeping the code and JavaDoc quality on par, testability and confident coverage, also including any vectors from the specs and capturing any potential issues with transcoding, invalid curve attacks and what may affect security.

‌

The JSON serialisation - we’ve had a feature ticket for years now and it has received multiple votes, but no API suggestions and certainly no PRs have been presented how to include support for that. We did not invest in the JSON serialisation because we have no use case for that. I had thoughts how it could be implemented with minimum coding and I believe it could work with a few classes for the JSON serialisation on top of the existing primitives, i.e. without the need to delve into changing current lib APIs. Such an approach could be a good first step to get a feeling of what’s actually needed, and then perhaps think about changing the lib APIs more significantly, for a more integrated support of JSON serialisation, including multiple recipients. If you happen to have ideas about that I’d be happy to hear them.

‌

Have you had previous contributions on similar crypto code? Or managing / reviewing such development?

[Alexander Shcherbakov]

Hi Vladimir,

Thank you for the comments and the interest to our contribution.

hat matters is keeping the code and JavaDoc quality on par, testability and confident coverage, also including any vectors from the specs and capturing any potential issues with transcoding, invalid curve attacks and what may affect security.

Yes, we will make sure that the code has good quality and covered by tests. And yes, we are aware of these attack vectors, so that specific checks will be added to the code.

Have you had previous contributions on similar crypto code? Or managing / reviewing such development?

Yes, we had.

In particular, our team was one of the authors and maintainers of hyperledger indy-sdk, hyperledger indy-crypto, hyperledger ursa, so we have experience in implementation, maintaining and managing such work, as well as working with the community.

‌

[Alexander Martynov]

Hi @Vladimir Dzhuvinov

Can you share your ideas on json serialization for jws, jwe? how would you implement multi recipients, should it be some kind of classes inherited from the Encryptors (such as ECDHEncryptor) and taking a list of Pair<Key, JWE Unprotected Header>?

[Vladimir Dzhuvinov]

My original suggestion here was to create a simple wrapper project (lib) that assembles the JSON serialised message by itself and uses the existing classes from the lib only to do the header construction and signing or encryption. Then in a similar manner disassemble a JSON serialised message for individual signature validation or decryption. This relies on the JSON serialisation involving BASE64URL encoded parts, which encoding can be handled already.

https://datatracker.ietf.org/doc/html/rfc7515#section-7.2

https://datatracker.ietf.org/doc/html/rfc7516#section-7.2

For example, JWSSigner takes JWSHeader and signing input.

https://www.javadoc.io/static/com.nimbusds/nimbus-jose-jwt/9.12.1/com/nimbusds/jose/JWSSigner.html

JWSObject has a helper method getSigningInput.

https://www.javadoc.io/static/com.nimbusds/nimbus-jose-jwt/9.12.1/com/nimbusds/jose/JWSObject.html

Let me know if that doesn’t make sense in some way.

I haven’t thought at all how to change the API of the library itself to handle such multi-recipient JSON serialisations. That’s why my first suggestion was to start with a wrapper, which should be way simpler and then based on that experience one might consider what needs to be updated within the lib APIs.

Do you need to support unprotected JOSE headers?

‌

[Vladimir Dzhuvinov]

JWE JSON serialisation, including unprotected headers, supported since v9.32.