Understanding Auth in HM Today

We currently identify each person or organization with one of two mechanisms:

1. Public Key Account IDs

A keypair, where the private key is either: derived with a mnemonic on trusted software, or stored in the browser's storage such that application code can never extract the key.

In either case we can refer to this as the KeyID.

2. Domain Names

For various reasons we want sites to have nice domain names. Which we already support through custom domains and *.hyper.media.

Through a (convoluted) API of HTTP GET <domain>/hm/api/config JSON .siteId, we can look up the current KeyID from the domain.

Note: this structure theoretically allows a domain owner to change the KeyID. But our software does not handle this very well. We also don't properly handle the case when the Account's siteUrl and the domain's published KeyID are mismatched.

Possible Insight

Rather than introducing another type of identity, we can create more elegant and powerful structures of PublickKeyID and DomainID.

When a user needs a portable identity across the web, they will just use a domain name.

Solutions

Improvement Proposal: Move host.s.h.m IDs to h.m

We already have a registration with an email confirmation step. It allows people to claim a subdomain on h.m, which may be treated as their username in our centralized system.

Logically, the authority for all h.m subdomains is not host.seed.hyper.media but rather it should be hyper.media. When people see content on bob.hyper.media, they will naturally go to hyper.media to see what is going on there, and possible to get their own domain.

The proposal here is to move all our existing email+subdomain combinations to hyper.media. So the "host" service will be integrated into our main h.m domain.

Thought Experiment: DomainID "Creation" is an external process to the HM protocol

We have a few goals:

Technical people will have the ability to create a soverign ID without relying on our infra
- Self-hosting accomplishes this
Nontechnical people will have a super easy process to get a name
- We could offer a traditional web2 signup process on hyper.media for this purpose
Nontechnical people should have a free sovereign and human-readable identities
- Accomplished with Custom Domains
We need to acquire customers and earn money
- Organizations who want to use SHM will either bring their own tech skills, or pay for our enterprise services
- Our enterprise service will allow those customers to create subdomain identities on behalf of their users
- We might not provide free software that allows NYT to give their customers bob.social.nytimes.com. But if NYT pays us, we can offer this alongside

In the case of our h.m domain, we would offer a login flow which involves email validation. This is an evolution of the existing workflow that allows you to sign in to host.s.h.m

Improvement Proposal: DNS-Focused Identity

For people who want to use one identity across the web, they can quickly/easily acquire a h.m subdomain, and use that domain to log in to any site.

Improvement Proposal: Login Strategy is to input your personal domain name.

For people who are self-hosting or who are using a custom domain with our service, they will input their personal domain. Example: gabo.es

This workflow will be used to log into the app, and for logging into any HM site.

Improvement Proposal: No email notifs without an account

To receive email notifications, you must create an account on h.m. This will help users realize who is providing the notification service.

Enterprise Offerings

Example1: Harvard wants to allow everyone with a bob@harvard.edu email address to create a subdomain at bob.social.harvard.edu. This would be possible with our enterprise offering.

Example2: Lunaticoin wants direct access to his subscriber list, and wants to send whitelabel emails.

Workflow: New User Subscription

To subscribe, you must be logged in.

Workflow: New Commenter on Self-Hosted Site

Imagine eric.vicenti.net is a self-hosted site or a free site on SHM hosting.

Soembody wants to create a comment. They see a Login button, and a button that says "Create Account on Hyper.Media"

Workflow: Log in with Existing Identity (different domain)

Gabo wants to use his main identity to comment on Eric's site. He clicks "Log in" and types gabo.es in the domain input box.

He is redirected to gabo.es, logs in, confirms the relationship to eric.vicenti.net, and then is redirected back. (See below for the login process that Gabo will follow)

Workflow: Log in to your own site

This workflow will be different depending on how you set up your site.

In a minimal self-hosting workflow:

You input a password from the CLI while setting up your server. There would be a CLI workflow for changing your pw.

From the web you would enter the domain name you are currently on, followed by your pw.

(this is also how we could allow our team to sign in directly to hyper.media)

If you are hosted by SHM, you follow our web2 workflow

Workflow: Log in to h.m, or social.nytimes.com

In the case of some domains, they will offer a workflow for logging in to a subdomain. This can be our own hyper.media domain, or an enterprise customer. If we decide to open source this workflow, it could be offered by a technically-capable self-hoster.

Basically, the login interface will allow you to input a username or email address, not just a domain. If you type a username/email address, you will follow a web2 authentication workflow. If you type in a domain, you are redirected to sign in on that domain you typed.

How all of this works:

In theory this could be accomplished if your domain serves a list of valid KeyIDs who are allowed to sign on your behalf. This works because the primary representation of an account becomes the DomainID, not the KeyID. When you Log In, a new key is added to the list. When you click "Log out of all devices", all other keys are removed from the list, and your new key must re-sign all content that it still considers valid.

Now for the "messy" part of the proposal: Capabilities would be granting and revoking access to domains, (although keys would also be possible for backwards compatibility and other reasons). This makes it a bit harder to be entirely offline-friendly because you can't validate caps without being online, but in practice this is not likely to be a problem. Also you should occasionally re-check the keys that a domain is offering, and you can gossip with your trusted network about which keys belong to which domains, even after those domains go offline. Aka the "distributed linkbase"