search

decentralized-identity / interoperability

The archive and information hub for the cross-community interoperability project. Focus is on education and familiarity for various efforts across multiple groups for interoperable decentralized identity infrastructure.
https://identity.foundation/interop/
Apache License 2.0
92 stars 19 forks source link

Pick a DID Method for the Credential Subject #3

Closed OR13 closed 5 years ago

OR13 commented 5 years ago

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.

OR13 commented 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.

OR13 commented 5 years ago

ethr

Any existing ethereum address is already an ethr did, might be a good way to engage the ethereum community.

OR13 commented 5 years ago

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.

rh7 commented 5 years ago

@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 ?

OR13 commented 5 years ago

@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).

OR13 commented 5 years ago

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).

OR13 commented 5 years ago

Closing this issue, the subject can be any universal resolver capable DID that can complete the DID Auth flow to be adopted.