Interested in a meaningful contribution? #237
Replies: 1 comment 6 replies
-
|
This library (in v3.x) makes use exclusively of platform available cryptography abstractions. That is the I think given some level of refactoring the additional cipher implementations and algorithm identifiers could be registered as some form of plugins. Would that be something you would be willing to contribute first?
JSON General serialization is already implemented for
The lacking JWE encryption one would be appreciated and welcome PR.
Once this is a stable[ish] IETF WG draft, sure. Until then I would recommend forking.
It's worth noting that the underlying Once there's at least one platform natively supporting the underlying cipher and this is a stable[ish] IETF WG draft, sure.
Not unless its implementation would be backed by Web Cryptography API. It is currently lacking implementer's interest. I would suggest to reach out to browser vendors to express their interest to support these in https://github.com/w3c/webcrypto |
Beta Was this translation helpful? Give feedback.
-
|
I imagine it could live in this codebase but would be distributed as a separate plugin package... it would use the (to be designed/developed) api hooks to register algorithm names, their implementations, and supporting values such as IV and CEK lengths. |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick shot at how the plugin thing could work...? https://gist.github.com/panva/55c7908d4193a854555e26fb83e503d4 Simply register the different algorithms for use with content encryption, or key management, and provide their implementation. one would then in code then its off to the races to use C20P as "cek" |
Beta Was this translation helpful? Give feedback.
-
|
@ashcherbakov wdyt? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the comments and interest to the contribution. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ashcherbakov I'm wandering what was the conclusion of the options you were evaluating? |
Beta Was this translation helpful? Give feedback.
-
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 JS libs for JOSE, we have concluded that JOSE implementation from your lib is closest to what we'd like to start from. But we need some new features:
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.
We can probably discuss contribution to backend (node.js) part and browsers part separately. node.js part will be a native code.
But as for 25519 support in the browsers, we are considering to implement it via wasm since Web Crypto API doesn't support 25519. Would you accept wasm-based implementation for browsers?
(Tagging @vimmerru and @dhh1128, who are interested in the answer).
Beta Was this translation helpful? Give feedback.
All reactions