Notes to readers: 

• The thinking for this post came as we prepare for the public launch of our AiP 1.0 mobile wallet app – and as we prepare to demonstrate AiP 2.0 compliance.
• This post assumes that the holder is already in full control of their interactions and relationships. It also assumes that the entire way of delivering digital ID is user-driven. This post is specifically meant to make the reader think about how to create more stickiness around credential issuance implementations.
• There is a need for better UX in SSI to spur more adoption – and we’re hopeful that “holder-driven credential issuance” can become a more common approach.

—

The process of credential issuance should be holder-driven

The holder must be somewhere in their user journey and have a specific need for a credential. At this point they need to provide some form of eligibility to claim a credential.

In Government-regulated scenarios, eligibility is often covered by foundational ID credentials. For example, “I’m a citizen of a country”, or “I’m of age of majority”.

The type of information exchange, whether as a credential offer received or a proof presented depends on the type of relationship that you wish to establish with the other entity. 

For example, you may not want to share your government-issued driver’s licence to all your peers as your proof of identity; you may want to share your digital driver’s licence with a financial institution to open up a bank account, but with others you may trust to share only your utility bill.

Relationships and personas

Even though the proof requests (for your identity) are the same in the above scenarios, the relationships you have with the peer entities (government-issuer and financial institution-verifier) differ for you (the subject). 

We can draw a similarity with what email addresses you would use to interact with different relationships of yours. You may use one email address to interact with friends and family, but another one to interact with work colleagues.

By introducing the concept of personas, you can start having separate DIDs for every different type of relationship you seek. You may want one DID for family interactions, another for your financial interactions, another for your work, etc.. 

You want to separate DIDs by personas because each persona has its own set of rules. And to establish a relationship, you must ensure contextual rules are met. This is how relationships are created and trusted. 

A wallet’s job in life is to securely and privately intermediate the interactions of a user. From an implementation perspective, every persona could create and be represented by their own wallet. And each wallet could have its separate DID to use to create separate connections. So you choose which persona to use; just like you choose which email address to communicate with another entity.

Establishing a connection (onboarding)

Now the question is how do you get onboarded? If it’s issuer-driven, can you trust a QRCode or any information presented to you if you’re unable to verify the provenance of the QRCode and information related to it? (Note: A QRCode is just an optical interface mechanism. If anything, a wallet should protect against QRCode fishing)

A connection request QRCode sent via email

Another key question is – why are they reaching out to you? People typically prefer to reach out to another entity they wish to engage with. You likely feel that calling your financial institution is much more comforting than receiving a call out of the blue from someone claiming they’re your financial institution.

Therefore rather than being presented with a QRCode, you should go to them, provide eligibility and then claim a credential. To claim a credential, you always need to provide eligibility. 

Eligibility is a verified email address, verified government ID, past references, skill-sets, etc.. Just like you go to Amazon, to a Government Service Desk, etc..

Managing a relationship

So now you have multiple personas, which helps you create different types of relationships which comply with the rules governing that relationship.

For example, one of the rules may be connection-based or connectionless-based relationships. 

Connection means that you consent to the entity tracking you so that you can build common trust. For example, you need to be tracked over time by a credit bureau for them to establish a credit score on your behalf. If the relationship is about building trust, then you want them to track you to some extent. 

But when you don’t need to build trust/relationship/tracking, you don’t require a connection, just a one-time interaction.. For example: doing an age check to purchase alcohol. 

You can also imagine short-lived connections for short-term relationships. And you can also reset the relationship if you wish to. For example, they may be collecting too much data on you – boom you reset it, create a new DID and your history with them is disassociated from the new connection you’ve established. Hence correlation is limited and in your control. Do you want to be tracked? Do you want your transactions to be correlated? As a holder, the choice is yours.

Within your connection management inside your digital wallet, you should be able to see the relationship level you have with other entities. You should be able to see how much you’ve shared and consented to. Do you want to reset your DID with them? Go for it – up to you, the holder.

All of this is very holder-driven – and during the onboarding process (e.g., creating a DIDComm channel/secure relationship) – the relationship is at 0. 

Only when you start sharing some eligibility information about yourself and claim a credential can you start establishing a >0 relationship. 

—

Special thanks to Pierre Roberge, Tim Bouma, Stepan Gershuni and Khalid Maliki for reviewing this article prior to publishing.