Decentralized UX: Designing Around Decentralized Identities

Decentralized UX: Designing Around Decentralized Identities (DDI)

Wednesday 6C

Convener(s): Bongani Mbigi & Jace Hensley

Notes-taker(s): Bongani Mbigi & Sarah Allen

Tags for the session - technology discussed/ideas considered:

UX, UI, Decentralized, Decentralized Identity, DID

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes from Bongani Mbigi:

Slides:

https://docs.google.com/presentation/d/11TuRRLsjISNfU9Kd97Uurxi1K5V80uCz8rRpe2n_850/edit?usp=sharing

POWER OF DECENTRALIZED IDs (DID):

Decentralized Identities(DIDs): DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.People and businesses can store their own identity data on their own devices, and provide it efficiently to those who need to validate it, without relying on a central repository of identity data.

MOST USERS DON’T CARE ABOUT UNDERLYING TECH:

Unfortunately despite all these advance features for the primary user these advanced security features rarely the focus of most users job. Your average user isn’t concerned about what D.I.D. method is being used but rather does this complete the task that is essential to my job. We don’t develop for the sake of software development. We develop with use cases and users in mind. User don’t care about DID addresses but care whether or not that the representative from a federal agency has verified their certifications.

BASICALLY THEY DON’T CARE ABOUT THE INTERESTING S**T:

We as specialists in this field have a vested interest in the finer details, that don’t necessarily interest the greater population.

USERS WANT SIMPLICITY

The Goal of every frontend developer should be improving the user experience. And for decentralized identities we have major pain points around onboarding, recovery, and discovery. Onboarding deals with how quickly can a user sign up and be able to utilize their identity. Decentralized IDs have the difficulty around the fact that did address are not easily human readable. It's not something that people would memorize. This leads into discovery. Discovery deals with how quickly can the find and interact with other identities and utilizes their identity with in other systems. Because did’s are not easily readable it is inherently harder to share with other systems and users. And Recovery is how easily a user can access their account when they lose their ability to authenticate. This is very difficult for DIDs. You may have lost passphrase or comprize your mnomic or private keys which renders your newly created identity out of your control. This jeopardizes not just your identity but verified credentials that are associated with that identity. This creates friction for users of DID and it not what users want or need. Users’ perception of a technology is based on the ease of use. Users want something that is as easy if not easier than what they are currently using. They Want they same speed of onboarding, and painless discovery and integration, and easy recovery when things go awry,

ABSTRACT AWAY UNNECESSARY DETAILS

It's important to abstract away what is not necessary for users to complete their jobs. For enterprise users, a good apps reduce friction and allows then to be more productive. For decentralized identity that means abstracting away unnecessary details. Remember every job has their own jargon and terminology, and adding our own jargon to their flow only complicates their jobs. We interact with names like Bongani M. from Transmute not did:eth:1234... . As we develop applications and refined the DID spec, we need to refine processes to resolve DIDs to something meaningful to our users.

We cannot ignore that when dealing with UX around Identities that there existing flows that users are accustomed to. It is necessary to utilize that. Skeuomorphism is something that helps bridge new technologies with existing systems and flows. When we can ground DIDS with existing experiences in helps users accept it as an evolution of what they see as their digital identity rather than change they would push back.

A general rule of thumb is make it so easy that <INSERT_SENIOR_FAMILY_MEMBER> can use it. Because for me, my mum would rather see Bongani @ Transmute rather than did:eth:1234. Process like Seeing TxHash 0x12bb123tfd… mean far LESS than Your “Bachelors_Degree.pdf” Verified By University of Texas at Austin.

FAQ

- HOW DO WE DO KEY RECOVERY?

-: Remember familiarity is key, we have existing methods like the secure enclave where we can safely back up their keys. You can also utilize the concept of an agent, i.e. working on behalf of your user, and hold their keys and manage it like traditional methods. Another method is to encrypt it using a paraphrase in which they can unlock their key. Another way is to revoke the lost / compromised key and have a back up.CYUA (Cover Your User’s A**)

- WHAT ABOUT POWER USERS?

-: This largely depends on your audience. For B2C this many not be an issue, for enterprise users you will need to be able to expose a power user mode for admin, in which they can see underlying ethereum transactions for auditing, etc. It is important to note Majority of users DO NOT need to or care to know this. So this should be on an opt in or need to know basis.

- HOW WILL THEY UNDERSTAND PRIVATE PUBLIC KEYS?

-: Largely depended on personal opinion. We believe that for most users we should abstract this for day to day uses. However It should be easy to find and see them. It is recommended to look for concepts in skeuomorphism: Find a way to related private/public keys to relatable things. Recommended: pub/private -> hand signatures && OAuth flow or literal keys

- LATENCY, LATENCY, LATENCY, BRUH

-: If it's not the user's responsibility, then don’t make it theirs. Hide it away in queues and resolve it on the backend

- REVOCATION?

- FURTHER READING:

https://medium.com/alpineintel/on-abstraction-and-risk-e981e06830f3

*********** *********** ************** *************** ************ **********

2. Notes from Sarah Allen:

Identity UX

Zuko’s triangle

• Human memorable
• Globally unique
• Cryptographically security

Pet name systems

Bloom - human side

• Initially Web app, meta mask based, but people found that difficult to use
• Created mobile app, which is a mobile wallet, but we don’t tell the users, they don’t care that it Is etherium-based

Meta Mask — Etherium wallet chrome extension — need seed phrase, lots of friction

Bloom app is an agent that is who they are

• Hide the details

Don’t have to wait for a transaction

— verifiable credentials can happen entirely offline

Transmute -

Agent is a useful concept, the agent does things on behalf of the user

B2B apps have clear authority (the company), 

• employees are comfortable delegating to the company
• Also people must do whatever the company says to do (everyone uses the same tech)

Use KeyChain on OSX, iPhone, Android also has a key store

When an DID is created, it’s kind of like an infant, it has no powers yet

Looking at verifiable credentials as capabilities has helped

Start with “What does the user need to be able to do?”

Key process improvements — iterate between UI designer and backend engineer

• Need to get your app in front of the user

Simple Cooperative Filesharing. (CHI Paper - on Alan Karp’s website)

• Unguessable URI
• Every policy decision has an artifact in the UI
• When you do someone does it feel like a security step or feel like regular workflow.  
• “If it feels like a security step, it’s an anti-pattern”

What are metaphors that work?

• Documents: each verifiable credential is a document
• Keys - refer to as digital signature (people understand that)

QR codes?  Debate about whether this is well-known or not.  Easy to learn, but can’t expect that people already know how to use it.

“Shield” — Transmute uses the term “shielded credential” who knows it has been verified. 

Lifecycle management for private keys?

• Lose phone with key on it
• How do I revoke / reset?

Backup private key to cloud, can move phones

Use agent, which can revoke compromised key

Enterprise can have key escrow (company has copy of your key)