Last year, I wrote about how digital relationships are operationalized in response to a post from Doc Searls about SSI wallets. The wallet (and the agent it is paired with) is a key player in SSI workflows. A recent exchange with the good folks at TechVision Research made me realize that I hadn't ever written about the patterns that an SSI wallet uses to realize operational digital relationships. Today I'm going to take a stab at three simple authentication and authorization patterns in SSI to show the interactions necessary to accomplish these foundational workflows. Finally, I'll show how all three are just specializations of the standard verifiable credential exchange pattern.

DID Authentication Pattern

The simplest authentication pattern uses decentralized identifiers (DIDs) as autonomic identifiers to establish a peer relationship. Because of their mutual authentication capabilities, DID relationships can be used for authentication.

This pattern has two parties:

• Alice has an SSI wallet on her mobile phone.
• Bravo Corp has an enterprise wallet tied to an IAM system that is protecting some resource.

The interaction pattern has the following steps:

1. Alice and Bravo establish a Peer DID relationship (blue arrow). This means that they each generate a Peer DID and send it to the other, along with the associated public key. These identifiers are self-certifying and each party can use the information associated with the DID to authenticate the other.
2. Alice tries to access the protected resource (red arrow). The request is intermediated by Bravo's IAM system. As part of this request, Alice makes her DID known. There are a number of sub-scenarios for the different ways this may happen. For example, she could scan a QR code or enter an associated human-readable identifier.
3. The IAM system, working in concert with Bravo's enterprise wallet, issues a DID Auth challenge to Alice's wallet through her phone.
4. Alice is notified by her wallet of the challenge and approves the response from her wallet to Bravo.
5. Bravo verifies Alice's response.

A few things to note about this interaction:

• Because Alice and Bravo are using Peer DIDs, no ledger is involved in the authentication. In a Peer DID relationship, both parties keep the other informed of relevant key events (e.g. key rotation) and store that information in a cryptographic key event log.
• Any authorization would have to be done based on information the IAM system has from another source. For example, if the Peer DID relationship were established within a different authenticated context, Alice could have been assigned a group for RBAC or other attributes could have been associated with Alice's DID within Bravo's IAM system.
• The interaction pattern shown here is leaves out a number of details. Markus Sabadello identifies ten different variations of this pattern in his talk Introduction to DID Auth for SSI.

Single-Party Credential Authorization Pattern

While the DID Authn pattern is simple, it is not as flexible as we need in some situations. For more complicated scenarios, we can use verifiable credentials. The first scenario we'll consider is where the same organization is issuing and verifying the credential.

The parties in this scenario are the same: Alice and Bravo Corp.

The interaction pattern proceeds as follows:

1. Since Bravo Corp will be issuing a credential, they write a Public DID and credential definition to the ledger. They might also write a schema and revocation registry, if necessary.
2. Alice and Bravo establish a Peer DID relationship (blue arrow). Note that the DID that Bravo uses for this relationship is not the public DID created in (1), instead Bravo creates a Peer DID especially for the relationship with Alice.
3. Bravo issues a credential to Alice (green arrow). The nature, content, and context of this credential issuance depend on Bravo and Alice's specific needs. Bravo is the credential issuer and Alice is the credential holder.
4. Alice tries to access a protected resource (red arrow). The request is intermediated by Bravo's IAM system. Like the DID Authn pattern, the IAM system is working in concert with an enterprise wallet.
5. Bravo is using a policy-based access control (PBAC) system that relies on knowing attributes about Alice. The IAM system makes a credential request to Alice that asks for specific attributes based on the attributes needed by the policy for the resource Alice is accessing.
6. Alice sees the request and authorizes her wallet to issue a proof of attributes based on the credential she holds. The response contains only the attributes that Bravo needs, not the entire credential to minimize the information that is shared.
7. The PBAC system uses the attributes in the proof presentation to authorize Alice's access.

A few things to note:

• Bravo does not need to access the ledger to verify the credential since they already know the information necessary to perform the validation since it's their credential. Even so, Bravo writes the public DID and credential definition to the ledger so that Alice can present the credential to others who can verify it, supporting use cases beyond Bravo's.
• Using a credential held by Alice to validate her authority to access the protected resource is more flexible for Bravo, and potentially more reliable, than a centralized attribute store. Rather than building a central attribute store and linking every system in the enterprise to it, each system can stand alone from the central store and make decisions based on the policies in place for that system.
• Astute readers will read the last bullet and think "but don't they all have to be linked to the same digital wallet to take advantage of the Peer DID relationship?" The answer is "no." Each service can have its own Peer DID relationship with Alice, verify the attributes from the credential, and know it's Alice. The only thing they need to know is the public DID their organization uses and the credential definition for the credential.

Multi-Party Credential Authorization Pattern

We can extend the single-party pattern, to include multiple parties. In this pattern, one entity, Bravo Corp, is issuing credentials, but another entity, Certiphi Corp, is verifying the credential and using its attributes to authorize Alice's access to a resource.

The interaction proceeds as follows:

1. Since Bravo Corp is issuing a credential, they write a Public DID and credential definition to the ledger. Again, they might also write a schema and revocation registry, if needed.
2. Alice and Bravo establish a Peer DID relationship (blue arrow).
3. Bravo issues a credential to Alice (green arrow).
4. Alice and Certiphi establish a Peer DID relationship.
5. Alice tries to access the protected resource (red arrow) at Certiphi. The request is intermediated by Certiphi's IAM system.
6. Certiphi is using a policy-based access control system so, the IAM system makes a credential request to Alice that asks for the specific attributes needed by the policy for access to the resource.
7. Alice sees the request and authorizes her wallet to issue a proof of attributes based on the credentials she holds. The wallet automatically chooses the credential from Bravo since it has the attributes needed to satisfy Certiphi's request.
8. Certiphi cryptographically validates the fidelity of the proof to ensure it's from Bravo, is about Alice, hasn't been tampered with, and hasn't been revoked. They might also need to validate the provenance of the attributes in the proof. Certiphi is the credential verifier in this pattern.
9. The PBAC system uses the attributes in the proof presentation to authorize Alice's access.

A few things to note:

• The DID relationship Alice and Certiphi create in (4) could be ephemeral, it needn't be permanent unless the parties need it to be.
• There is no direct connection or link between Bravo Corp and Certiphi Corp. They needn't have any pre-existing business or technical relationship. Certiphi needn't connect to a Bravo Corp API.
• The primary difference between the single-party and multi-party patterns is step (8), checking the fidelity and provenance of the credential. The fidelity can be done automatically using cryptography. Determining provenance is not a trivial thing since it involves Certiphi determining they can trust attributes attested by Bravo. This is a governance issue, not a technical one.
• The governance issue could be simple or complex. Perhaps Bravo is known to Certiphi (e.g., a local business next to a large university). Certiphi might ask Bravo to prove things about itself using credentials issued to Bravo by someone Certiphi already trusts (e.g., the government). Bravo and Certiphi might already be part of some established governance framework (e.g., a university accreditation organization).

Generalized Trustworthy Data Transfer Pattern

Authentication and authorization are table stakes for any identity interaction. The general data transfer pattern moves beyond simple authentication and authorization patterns to using identity data in workflows.

In this pattern, all of the interactions are identical to the pattern for multi-party authorization in the last section with a few exceptions:

1. Alice is accessing a web service that needs data to proceed in (5) rather than a protected resource.
2. The web service uses the data from the proof presentment as part of its workflow (e.g. fill out a form).

We can view all of the previous patterns as specializations of this pattern:

• The Peer DID relationship provides a mutually authenticated communications channel in every case that can always be used to know that you're talking to the entity with whom the relationship was originally established–the core requirement for any authentication.
• Transferring attributes using verifiable credentials for PBAC is just a special case of transferring attribute data in a trustworthy manner. The difference is the end-use of the attributes: the PBAC system or some other service.
• There's no need for the data transferred in the general pattern to come from a single credential. In fact, the service can ask for attributes without knowing what credentials Alice holds. Alice's wallet will match the requested attributes to the credentials Alice holds. Alice can choose which credentials to use for specific attributes (e.g. date of birth) if she wants.
• While the figure shows Alice accessing a web service, this can be further generalized beyond the web. Any data transfer for an online workflow can happen using verifiable credentials.
• While this pattern involves Alice and two organizations, there's no reason why people can't be credential issuers and verifiers. Indeed, any party in these diagrams could play any of the roles.

Viewing traditional IAM functions like authentication and authorization as special purpose data transfers broadens SSI significantly beyond what we have traditionally seen as "digital identity." The uses for verifiable credentials are vast and include many things we may not think of as "credentials". While this expanded view of digital identity may make some uncomfortable, I think it is perfectly aligned with my belief that we build identity systems to manage relationships, not identities. Every relationship is unique. Flexible, trustworthy digital credentials serve that uniqueness and introduce the means of moving digital identity beyond just authentication and authorization.

Photo Credit: Phone Icon from Fast Icon Design (Linkware)