Investigate Web Authentication

Problem

We want to bring commenting to the web, and eventually document editing. But we have some problems with authentication on the web:

Our authentication system is cumbersome, most users don't understand what are the twelve words and why they need them

Users might loose their seed, or they might

There is no way to easily sync their seed to other devices

Solution

This project is an investigation. So it will probably not result in production-ready code. The goal is to understand the problem, create a prototype, and create a more complete proposal.

It would be nice to use passkeys because they offer the following mechanics:

Strong local security, especially on apple devices where they are stored in a security chip

Syncing across devices

Relatively familiar UX for users

Summary of Passkey Approach

When the user needs to sign something, such as a comment, they can use a passkey to "login/register". This process will create a signature based on the challenge. A challenge is usually random data generated by the server.

But we can abuse this API and pass the comment/change data as the challenge. The account ID will need to somehow reference the public key that is being used, and

However, there are many roadblocks for using Passkeys!

Problem: Identifying the key

A passkey is roughly identified by the site's domain + a user ID. This is ideal for passwords but not ideal for us. What user ID should we use? An email address that the user supplies and the site verifies? Would it work to use the same user ID for every user? Is it possible for one user to have multiple signing identieis on a single site?

Problem: Sharing Identities between Domains

A user might want to use the same identity to sign content across several custom domains. This is not possible with passkeys.

Passkeys supports a "Relying Party ID" but it only allows subdomains to access the identity oned by a parent domain. Custom domains are not supported!

Problem: Passkey UX is not Great

We want to remove friction for the user to comment and interact with Hypermedia sites. This requires several extra clicks in chrome, and often requires biometric interaction.

Also, the signing prompt is confusing. Every prompt will probably say "Sign In" beyond the first signature. And the security isn't very robust because the site can sign anything on behalf of the user- they don't see what they are signing, so its not very secure.

Eventually we will want a "like" button or other reactions like "👎" and it would be really inconvenient if the user has to sign with passkey every time they react. I think this would dramatically reduce the number of people who "like" content on HM websites.

Problem: Cannot Share Account ID with App

Users will probably be annoyed that their web IDs are different from their ID in Seed app. Eventually we can mitigate this issue with Contacts, but it would be better to not fragment identities in the first place.

Problem: Account Name + Metadata

How do we set and get an account name for web identities? The desired UX is probably:

Prompt the user for display name when commenting for the first time

When commenting again, automatically show their display name before they comment, so they can see what name will be displayed

Alternative: Seed Phrase with Local Storage

If these challenges prove too great, we can consider a custom implementation involving a seed phrase where the signing key is saved in the browser's storage like localstorage or IndexedDB. This would allow shared identities with the app, and improved UX after sign in. But it means the user will need to understand how the seed phrase works, and will need to manually save it and sign in on every device.

Cross-Domain Strategy

In either implementation (passkeys and local seed phrase), we will have troubles using the same user identity on different sites. So we might want a system where one site can authenticate data with another.

Say a user wants to use their hyper.media identity from bob.com . They would create a comment and click "authenticate with hyper.media"

(optionally specifying a different domain to authenticate with)

But the UX for this is not great.

Implementation Strategy

1a. Implement the Comment Editor

We will definitely need an editor so that comments can be drafted. We should get a basic editor ASAP, and then iteratively bring over features from the app

1b. Research Web Signing methods

This project. Understand how signing can work, and create a prototype

2. Backend Implementation

The JS app will deliver a signed comment blob to the daemon, who is responsible for validating the signature. If it looks good, the daemon will distribute the comment over p2p

3. Test/Iterate

Experiment in production behind a feature flag, so we can get a feel for the experience before rolling it out to all sites

Activity