Closed OR13 closed 5 years ago
elem
I'm biased here, and elem
is not in the universolver yet, but we do support free DID creation via a single page web application, its an easy onboarding experience, if not a totally safe one, since elem
is still under active development.
ethr
Any existing ethereum address is already an ethr
did, might be a good way to engage the ethereum community.
github
I'm biased here, its not in the uniresolver, and its centralized, but it is free to create, and is naturally linked to both github users and organizations.
@OR13 - I hope I don't misunderstand the issue. I expected that we need to support many different DID methods to demonstrate that various wallets can be used in this PoC? I guess we could define that it needs to be part of the universal resolver, but I assume that could be addressed also for elem
. @peacekeeper ?
@rh7 yes I believe this is the goal, however if the DID method is not in the universal resolver, custom code would need to be added for each method. The purpose of this ticket is to define how much custom code we plan to add to support the project.
I would recommend just using the universal resolver, its going to give us the widest coverage for least effort, for our first phase.
Also regarding wallets, they are where the real challenge comes in. Its easy to support a DID method, but the various wallets could add a lot of complexity since there is not really a standard DID Wallet definition like there is for the resolver. If seeing the credential in a member org wallet, like uport is a requirment, we can only commit to support a few (like 2) to start IMO. However, we can make the credentials accessible (public) and link them to DIDs we don't need to tackle wallet storage for first version IMO (its likely to be the most challenging part of this project IMO).
After we gather a bit more feedback, I'm happy to close this issue and adopt support for credential subjects that are resolvable via the uniresolver (for phase 1, we can add support for others later).
Closing this issue, the subject can be any universal resolver capable DID that can complete the DID Auth flow to be adopted.
IMO this one is far more important since there will likely be many subjects all wanting credentials from a single issuer.
This means that cost should be considered, as well as ease of creating and managing your DID.
In order for the issuer to authenticate the subject before issuing a credential, the subject will be required to provide a signature, so again usability will be key.
I guess technically we don't need to limit the credential subject to a specific DID Method, assuming we rely on the https://uniresolver.io/.
It is the case that a resolver is required to authenticate a DID, so supporting the DID Methods the uniresolver supports seems like a good idea.
Add your favorite DID Method or vote for one.