Lately, I've been thinking a lot about use cases for self-sovereign identity. This is the first in a series of blog posts that discusses how Sovrin can be used for various purposes. We'll begin with authentication.

Authentication has several facets. I’m going to discuss two of them below: enrollment and login. In this use case, a person named Alice will be enrolling and logging into a service provided by Bob’s Bait Shop.

Enrollment

How does Alice get a self-sovereign identity? If you read my How Sovrin Works article, you should be aware that there’s no such thing as “an identity” in Sovrin. Instead, Sovrin creates a unique identifier for each relationship that Alice has. Alice controls her identifiers and can correlate them, but no one else can without her permission. So, enrollment consists of Alice generating a key pair for a new relationship and the Bob’s Bait Shop associating that with an account.

There are different ways this could work, but let’s explore just one that involves a Sovrin app called a connector. The connector runs on the person’s device and helps them manage their keys. In some ways, it would feel like a password management app such as 1Password. The connector is secured by the operating-system security services on Alice's device as well as app-specific mechanisms.

When Alice wants to connect with Bob’s Bait Shop via a Web site or mobile app, she uses the connector to generate a new Sovrin public-private key pair for that relationship. The connector securely stores the private key, then uses the public key to generate and register a new identifier on Sovrin. Alice gives the identifier to Bob’s Bait Shop, who creates an account and associates the internal account identifier with the Sovrin identifier. This association could be memorialized as a claim.

If desired, Bob’s Bait Shop could generate a challenge that Alice signs with her connector to prove that she gave them a real Sovrin identifier.

Bob’s Bait Shop might also ask Alice to provide information for creating the account. The connector would automatically determine which claims (either verifiable or self-asserted) can be used to satisfy the request, obtain permission from Alice, and then transmit those claims to Bob’s Bait Shop. Sovrin can partially disclose the information in the claims to protect Alice’s privacy.

As part of requesting information from Alice, Bob’s Bait Shop could send a consent receipt that records promises made to Alice about how her disclosed information will be used. The connector stores a hash of the consent receipt on the Sovrin ledger to notarize it.

Note that Alice didn’t create a password or fill out forms. And she received a receipt documenting her consent. The connector remembers all of the services with which she’s enrolled and gives her a single place where she can see everyone with whom she has a relationship¹.

Bob’s Bait Shop doesn’t store or manage passwords. They didn’t have to validate email addresses or phone numbers (provided they received claims they trust). And yet, they have a secure method of authenticating Alice and account information they can trust.

Login

User authentication is the most obvious use case for any identity system. Based on the discussion of enrollment above, assume Alice and Bob’s Bait Shop have already exchanged an identifier and that Alice’s connector is storing the corresponding private key as well as an identifier for Bob’s Bait Shop that can be used as a public key.

Authentication is done using any of the standard public-private key authentication schemes. One method consists of Bob’s Bait Shop presenting Alice with a one-time challenge string (i.e. a nonce) that her connector signs with the private key associated with the service. Bob’s Bait Shop can then use the identifier they have stored to validate the signature. Since only someone with the private key could generate the signature for that identifier, they know they are dealing with someone who has the private key.

Because the challenge is a one-time random string, the authentication can’t be replayed. And Bob’s Bait Shop is not relying on passwords that they have to store (and could lose). In fact there’s nothing for hackers to break in and steal.² From Alice's perspective, logging in feels as simple as pushing a button in the app and touching the fingerprint sensor on her device.

Benefits of Sovrin Authentication

Authentication might not be very sexy as use cases go, but it’s universal. Sovrin provides an identity system supporting easy enrollment and strong, cryptographically verified authentication that reduces cost, friction, risk, and liability.

1. The connector, like a password management app, has a way to sync keys across different devices the person uses. They are not dependent on a single device.
2. By stealing account information, hackers could still set-up a phishing attack where they pretend to be the the original service in an effort to trick the account holder. To counter this, the connector could simultaneously issue a challenge to the service that they have to sign using the private key associated with their well-known public identifier.