---
# System prepended metadata

title: Charting a path for DIDAuthn

---

# Charting a path for DIDAuthn

:warning: **NOTE: WIP DRAFT**


With the W3C having recently approved the Decentralized Identifiers (DIDs) v1.0 spec as an official web standard, The two primary questions that come to mind for many is: 
* How can we introduce the use DIDs to empower, improve, and simplify our lives? 
* What aspect of DIDs can we leverage in order to do this?

A short blurb from the [W3C press release](https://www.w3.org/2022/07/pressrelease-did-rec.html.en) can help point us in a compelling direction:

> DIDs have the unique property of enabling the controller to verify ownership of the DID using cryptography. This can enable any controller of a DID — an individual, an organization, an online community, a government, an IoT device—to engage in more trustworthy transactions online. For individuals in particular, DIDs can put them back in control of their personal data and consent, and also enable more respectful bi-directional trust relationships where forgery is prevented, privacy is honored, and usability is enhanced.

After reading this, something that immediately comes to mind is the traditional account registration and log-in flows we've all grown accustomed to despise. The universal reaction to either of those flows is :unamused: . It's full of user friction and is inherently centralized. A grand total of 0 people on this earth enjoy signing up for a new site and holding on to a password. Thankfully we can leverage DIDs to do away with both. Let's state our goals plainly:

## Goals
- Decentralized password-less sign-up/login across all of your devices with seamless account recovery mechanisms. 
- Decrease user friction and centralization while increasing security

> Consider posing the No Username narrative of user-owned personas and persona reuse option a primary goal.

Alright dope, we've identified a problem to solve and we have a proposed solution. Now how do we actually achieve the goals we've established?

## Charting a Path
Decreasing user friction is table stakes. If we want a truly seamless user experience, it has to work across all devices (mobile and desktop). Sensible recovery mechanisms are also an absolute must. Moreover, there should be no expectation of individuals to understand or even remotely know about DIDs or PKI. In order to achieve such a feat, we're going to need broad adoption across browser and mobile device vendors. Broad adoption of any new technology is often an uphill battle fought on many fronts that plays out over several years. Is there anything we can do to streamline the adoption of DIDs?

:warning: _**TODO**: improve paragraph below_

Thankfully, a lot of incredible work to enable password-less sign-up/login has been well underway for quite some time now in the form of [WebAuthn/FIDO2](https://webauthn.guide/). WebAuthn [^1] is a standard developed by FIDO and W3C with active participation from Google, Apple, Microsoft, Yubico, and others. The WebAuthn API allows servers to register and authenticate users using public key cryptography instead of a password. The associated private keys are kept secure within [CTAP2](https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html) compliant platform or roaming authenticators (e.g. YubiKey, Apple's TouchID, Windows Hello). As of January 2019, WebAuthn is supported on Chrome, Firefox, and Edge, and Safari with Apple recently revealing PassKey built atop WebAuthn. 

:warning: **TODO**: _include browser support chart_

So why all this talk about WebAuthn? here's why: 
- both WebAuthn and DIDs rely upon public key cryptography for authentication 
- WebAuthn already has significant adoption by major browser vendors

Well, what if we considered the possibility of incorporating DIDs into WebAuthn? It certainly feels like an idea worth entertaining given the progress WebAuthn has already made. The next question that comes to mind is, what do DIDs bring to the table that WebAuthn doesn't already have?

:warning: **TODO**: Rework paragraph below. Maybe feels a bit too ranty? 

Despite WebAuthn's use of public key cryptography, the traditional account ownership model remains unchanged where your digital identity is merely _afforded to you_ and far from _owned by you_. Your online identity is `@your_twitter_handle` or `your_email_address@bigcompany.com`, and hell, you're even registering for / logging into other platforms using those handles to prevent from having to create yet another identifier. Sit back for a minute and think about how reliant your digital identity is on your email address or phone number. These identifiers can be taken from you on a whim. 

DIDs tip the scale back towards the individual by making the your the sole owner of your identifier. The handles/aliases provided by sites are simply _associated_ to your identifier. So, even if you are banned by an email provider or social network, you maintain sole ownership of the root of your digital identity - your DID.

Let's recap with a TL;DR - WebAuthn + DIDs = :100: 

## Next Steps
First things first, if any of what's been stated above is outright wrong or delusional; or if there's a better path forward, definitely don't hestitate to call it out. If not, maybe we can focus on:
* Solidifying the narrative around how the addition of DIDs benefits WebAuthn
* Writing up an RFC focused on the least intrusive incorporation/augmentation of DIDs into [WebAuthn](https://w3c.github.io/webauthn/#sctn-intro) / [CTAP2](https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html)
* Implementing a prototype of this RFC that can be provided alongside the RFC
  * Could fork a virtual fido-compliant authenticator like https://github.com/bulwarkid/virtual-fido
* Getting involved in the appropriate working groups to formally present the idea.

:warning: **TODO**: Resume here


## Notes

### Acronym-Soup Dictionary
* **Authn** - Authentication
* **FIDO** - Fast IDentity Online. The FIDO Alliance is an open industry association with hundreds of member companies, working to create authentication standards to help reduce the world’s over-reliance on passwords.
* **CTAP** - Client To Authenticator Protocol. It describes how authenticators can implement second-factor and passwordless authentication. These authenticators can be built-in to devices like phones and laptops (on-device or platform authenticators), or they can be external ones (roaming authenticators or security keys) connecting over NFC, USB, and/or BLE.
* **CTAP2** - Support for password-less authentication
* **FIDO2** - overarching term for WebAuthn + CTAP2



### WebAuthn Highlights
- WebAuthn spec written by FIDO and W3C with active participation from Google, Apple, Microsoft, Yubico, and others
- Provides the type of frictionless UX we're looking for
- WebAuthn API is supported in the Chrome, Firefox, and Edge browsers to different degrees, but support for credential creation and assertion using a U2F Token, like those provided by Yubico and Feitian, is supported by all of them. Apple's PassKey is built atop Webauthn
- The WebAuthn API allows servers to register and authenticate users using public key cryptography instead of a password.
- Key management is handled by roaming (e.g. yubikey) or platform authenticators (e.g. touchID, Windows Hello)

### 

### Challenges
* The sentiment regarding DIDs has carried a negative undertone due to the assumpton that DIDs necessitate blockchains and with blockchains comes shitcoinery, scams, and rug pulls. This may cause some friction within the working groups that have been established to push WebAuthn forward

## Helpful Resources
* [Official WebAuthn Guide](https://webauthn.guide/)
* [WebAuthn Demo](https://webauthn.io/)
* [WebAuthn Spec](https://w3c.github.io/webauthn/)


[^1]: If you're interested in WebAuthn, Auth0 has a great interactive demo available at https://webauthn.me/ which showcases how Webauthn works. Duo has one available as well at https://webauthn.io/ which really highlights how simple registration and login can be with WebAuthn.