Hi devs, In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API. In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities: 1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API. 2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC. 3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well. I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world. WDYT ? -- Denis Gervalle SOFTEC sa - CEO