How to allow users to only have one identity?

Hi All,

I have a question; is there a technical possibility to restrict users to only have one account on a network (from a technical prospective)? Don’t know if this is the right place to ask this question… Hope you guys (and girls) can help out!

Many thanks,

Joost

Hey, what do you mean with “account”?
In Indy/ Sovrin you use DIDs. You could restrict the amount of DIDs a user can have on the app layer.

I am not asking this explicitly for Sovrin, but more in general; with account I meant a login as you would have for an email address for example. So basically if there is a technical method for someone to only have one login for a specific network. Using identification methods for a central authority would be a possibility, but I would like to have a system not dependent on such authorities as I would like to aim at the world population, so also for areas where there is less of a stable government system. Bio-metrics might be an option, but I am not familiar enough with those technologies to assess if those are exclusive enough. Other possibilities might be to have someone indicate his biological parents or such, strengthening the account/identity/login by the amount of connections in the network. Maybe there are other/better option of which I haven’t thought of yet. Hope you can help!

Many thanks!

Credentials are at the core of the Sovrin ecosystem. Remember that the three main actors are the credential issuer, the credential holder, and the credential verifier. (A good description is in the Appendix to the Sovrin Glossary.)

When the user signs up for the service, the service provider invites the user to establish an encrypted side-channel connection and exchange pair-wise DIDs. This is done by asking the user to use their identity agent to scan a QR code or load a specific URL.

The service provider then uses that channel to issue a credential to the user stating that the user is authorized to use the service in a specific capacity. The user’s identity agent holds that credential in their wallet.

When the user logs into the service, the service provider is now acting as the verifier. They use the encrypted DID communication channel to send a credential request to the user. The user responds to the request with a proof of the credential showing their authorization to use the service. The service provider can then provide a session token to the user that is valid for the main communication channel.

There is an ongoing effort to include a bridge between DIDAuth and OpenID Connect that implements this flow out-of-the-box for certain IdP solutions.