Problem

Currently domains can link to a single key ID

HTTPS vs DNS key association

For the destination URL, take the domain. On the domain, do a GET to /hm/api/config and extract the registeredAccountId field from the resulting JSON object.

This process is a bit strange, which is not that big of a deal. Ideally you could send an OPTIONS request to any HM domain, and get the relevant details from the response headers. Avoiding the JSON overhead and improving perf for browsers who have CORS requirements to send the preflight request.

Also, this technique requires web hosting. And the user might only be paying for a DNS server- no HTTPS server. So we should allow the user to specify a DNS TXT record to identify the key(s). But we should continue supporting a HTTPS workflow, because this allows the user to delegate some responsibility to a web server if they want to.

The best solution is to support both:

The DNS approach like AtProto- no web server required!

HTTP approach like SHM24, which allows the server to change the key without changing DNS data (which is an inconvenience for most users)

Multi-Key association

Currently there is only one key per domain. This is not ideal because the user might be signing in to their identity from a new device. The server can validate that they are the correct user (through a secret password or email verification, for example). Aside from rotating the main identity key, the user cannot log in to their account.

Solution

Very rough right now:

A. Allow servers to identify their key- not the published site key, but the key that is actually in the server

B. The server key signs a validation for each session key.

C. New mechanism for key association. Options request to domain root. Result headers will include:

The published site key ID

The server identity key ID

Signed validations for each session key

D. DNS:TXT driven identity publishing