replace usage of nimbusds Algorithm and Curve with our own enums

[mistermoe]

Currently, Crypto, KeyManager, and DidKey expect nimbusds JWSAlgorithm and Curve arguments for various methods. we should implement our own enums and use those instead. surfacing a dependency's enums as arguments to our libs causes confusion. Confusion == kaka DevEX

[andresuribe87]

surfacing a dependency's enums as arguments to our libs causes confusion

@mistermoe can you elaborate on what confusion this is causing?

The way I think about it is:

• JWSAlgorithm represents any entry in the JSON Web Signature and Encryption Algorithms table.
• Curve represents any entry in the JSON Web Key Elliptic Curve table.

[mistermoe]

yep,

• JWSAlgorithm is confusing from a naming perspective
• we're asking callers to pass in types from third party libs
  • walking away from nimbusds will lead to breaking changes for our public api surface
  • if nimbusds changes these types in subsequent versions, we can get stuck on older versions or sort of be at the mercy of their public api surface

[bradleydwyer]

we're asking callers to pass in types from third party libs
walking away from nimbusds will lead to breaking changes for our public api surface
if nimbusds changes these types in subsequent versions, we can get stuck on older versions or sort of be at the mercy of their public api surface

@andresuribe87 This is the core issue for me. I believe if we are to provide tools for decentralised identity that we should commit to providing the types necessary to support that. I can also see a lot of benefit in a single narrative/style for how we present our SDKs, of which types are a significant part.

[decentralgabe]

@mistermoe can you provide an example of our own enum to illustrate how it'd simplify things?

[tomdaffurn]

We're exposing other Nimbus objects, such as JWK. Thoughts on making our own?

[andresuribe87]

Thoughts on making our own?

Yes, I think we should make our own. In general, I think we should follow https://jlbp.dev/JLBP-2. In particular, "Avoid exposing types from your dependencies".

So this issue can be split into two categories of tasks:

1. Avoid exposing types from your dependencies by replacing them with our own types. This includes Curve, Algorithm, JWK, and some other types from the com.danubetech package.
2. Decide what the best API surface for the types that's being replaced.

For 2, related to Curve and Algorithm, there has been discussion in TBD54566975/web5-rs#38 and in TBD54566975/web5-js#271. The proposal is to one of: KeyType and Algorithm + Optional(Curve) and AlgorithmIdentifier. I think it makes sense to focus this issue on the decision of which of the three different abstractions we'll go for, and then make the appropriate changes.