JOSE implementation options

# JOSE implementation options The current document raises a question if we want to have all implementations for a DID Comm in the target language, or we should rather create a common library with common code and language-specific libs will depend on it. ## A problem with current JOSE libs DID Comm is based on JOSE. But the parts we need for the MVP are not part of usual JOSE RFCs and hence they are usually not part of common JOSE libraries: - ECDH-1PU - Key Wrapping algorithms for X25519 - EdDSA (Ed25519) - XC20P So, in many cases it doesn't make sense to use and depend on standard JOSE libraries at all. Forking is questionable, as we don't have any guarantee that our contribution will be accepted. This is actually how other DID Comm implementations are done (AcaPy, AriesGo, didcomm-rs). They all implement JOSE headers and format in their code, and use some crypto libraries and primitives for the required crypto operations. They don't depend on any standard JOSE lib at all. ## Options Overview So, it looks like we may have the following options: 1. **Custom JOSE logic on the DID Comm lib level** - Every language-specific library will implement their own version of common JOSE and some crypto algorithms. - No need to depend on the standard JOSE libs in a general case - We choose the most popular implementation for low-level crypto (curves, signing, encryption) - ECDH-1PU (and probably ECDH-ES) will be implemented in the DID Comm library - JOSE format and headers will be implemented in the DID Comm library - Only required dependencies and algorithms will be used 2. **Fork the most popular JOSE lib** - Fork the most popular JOSE lib and implement the required changes there. - DID Comm libs will depend on that fork 3. **Common lib (JOSE or DIDComm)** - There is a shared implementation of crypto (ECDH-ES, ECDH-1PU, etc.) and probably some JOSE primitives written in, for example, Rust or Kotlin. - Shared crypto lib uses popular low-level crypto libraries specific for the common lib language (Rust/Kotlin) - Shared crypto lib has wrappers for all needed languages (as in indy-sdk) - Other language-specific libraries use the shared common lib internally, but still have the API idiomatic for the language. - Language-specific libraries depend on neither JOSE nor low-level crypto libs As JOSE and crypto algorothms is the major part of DID Comm, Option 3 can can be extended to **Option 4: Common DID Comm Lib**, where all DID Comm logic is implemented once, and language libs are thin wrappers around it (as in indy-sdk). ## Options Details 1. **Custom JOSE logic on the DID Comm lib level** - Pros - Easier to understand and maintain for people targetting the given language. If the lib is in Python, and there is a need to do a change or fix in the common logic, there is no need to go and do the change in Rust (which can be tricky for a person who doesn't know it). - Crypto implementation specific for the given language is used. - Easier to support the DID Comm libs of the common platforms for the language. - No need to understand and dig into implementation of a JOSE for the given language - Potentially less dependencies as only required algorithms and crypto are used - Cons - Duplicate code and logic - Need to test JOSE related part properly (for example, that JOSE message is built correctly) 2. **Fork the most popular JOSE lib** - Pros - There is a chance that changes in out fork will be accpeted in mainstream - Can help community to improve existing JOSE libs - The DID Comm lib will be smaller as it will not contain crypto/JOSE specific implementations - Cons - Need to understand and dig into existing JOSE implementations - May require quite a lot of changes or additional dependencies for JOSE library - We may choose a wrong library to fork/contribute in case of multiple similar implementations - Potentially more dependencies for our libs (we may not need all the algorithms for DID Comm) - Not so clean dependencies in DID Comm, as we will have to depend on a fork of JOSE in every DID Comm lib. May need to distribute the JOSE fork separately from the upstream. 3. **Common JOSE lib** - Pros - No code duplication - Cons - Maintenance and implementing changes/fixes can be more tricky - More complex dependency tree If a standard JOSE library implementing all required algorithms and crypto appears for some language, all options can support migration to this lib: - Option 1: Just replace custom code in the DID Comm lib by the standard JOSE lib for the given language - Option 3: Just replace common JOSE lib in the DID Comm lib by the standard JOSE lib for the given language