Supporting new DID Methods

[elribonazo]

We're debating around adding support for additional did methods to Identus with the objective of increasing interoperability with other platforms, bridging the gap with other existing identity projects that are not using prism:did.

Castor building block was designes to provide flexibility on which methods are used for did resolution and did creation and should be configurable by adding resolvers for the specific did methods.

Value

1. It makes Identus interoperable with other projects outside of Cardano and prism:did.

2. Will make it easier to other projects to onboard into Identus.

3. It enables diversity on which did methods can be used in Identus, as each did method has its own feature set, this would allow any project with specific did related needs to use Identus.

4. Enabled specific use-cases that are not supported by prism:did Today.

Development plan

• In Identus OAS, Castor must be more flexible and agnostic by default on which did method is used, allowing anyone to add their own did resolvers.

• Ensure documentation around how to create and integrate your own did resolvers in the Agent and the SDK's.

Alternative did methods

• did:tdw
• did:key
• did:web
• other platform specific did methods

Feel free to add comments and propose new did methods that we want to bring to the discussion and poll.

[FabioPinheiro]

I always try to advocate for this. With a special goal in achieving interoperability with others.

For the Identus cloud agent this is not that far away to be achieved right now. This was a concern of mine when reviewing Pull Request.
I believe that the core for the library that I created is also a great addition to make everything type safe in Scala. https://github.com/FabioPinheiro/scala-did/tree/master
On the core Jar I tried to only defined the types according to the specs. Also many type are opaque type for runtime optimizations (they don't exist at runtime).

[mixmix]

I think our (Matou's) offline-first approach would mean that did:key is something we'd like to see support for. Honestly we've not being using did:prism much yet, there is a very open question about how VDR should best be done in our community context. We really do not want to build a monolithic "source of truth" around identity, this has some dangerous political and cultural implications (I think).

We do want to support communities to choose the right level for them. We currently suspect that new communities would really appreciate a low / zero centralized infrastructure approach, but as they grow will likely start to see the need (and benefit) for such a thing to exist (as they start to use identity tools to coordinate with more and more groups beyond their immediate community)

[robertocarvajal]

Regardless of what DID method gets added, the main goal should be to enable common interfaces to easily add support for creation of any DID method, I guess the first step is to implement the support of DID Prism trough this interface.. this will also help adding support for DID Prism to the universal-registrar

[FabioPinheiro]

Fully agree!
In the could agent have quite a lot of work to get to that point.
In the mediator this is almost true. (it was already in the past)
In the SDKs I think it's also very doable to make this a reality.