auth: HTTP priv/pub key auth

[domdomegg]

Add HTTP-based authentication to prove domain ownership, similar to #238's DNS authentication but using HTTPS well-known URIs instead of DNS TXT records.

Motivation

Some organizations don't have easy access to DNS records, but can easily deploy web assets. They would therefore prefer to be able to complete a HTTP challenge rather than a DNS one to authenticate to the registry.

This would in some way mirror ACME challenges: where you can do a DNS-01 or a HTTP-01 challenge.

Proposed Implementation

1. Public Key Hosting

Domain owners host their Ed25519 public key at:

https://example.com/.well-known/mcp-registry-auth

(better names/ideas for paths welcome! although I don't think blocks implementation as is probably a one line change if we want to fix later before go-live)

Response format (plaintext, format to match the DNS records):

v=MCPv1; k=ed25519; p=MCowBQYDK2VwAyEAja8L6VAIuWaXJLxDXBFf...

Multiple keys can be specified by just having multiple lines

(Alternative considered:

• JSON format of the above e.g. { "v": "MCPv1", "keys": [ { "id": "key-2025-01", "algorithm": "ed25519", "publicKey": "MCowBQYDK2VwAyEAja8L6VAIuWaXJLxDXBFf..." } ] }. But I think there's something nice about it being the same as DNS given how similar the two implementations will be.
• JWKS format)

2. Authentication Flow

Basically the same as DNS, except you only get access to the challenge domain (rather than the domain + its subdomains). This is to reflect the difference between DNS and HTTP, where DNS implies hierarchical control but HTTP does not. This mirrors similar protocols as well, e.g. like ACME challenges.

POST /v0/auth/http
Content-Type: application/json

{
  "domain": "example.com",
  "timestamp": "2025-01-16T18:56:49Z",
  "signature": "<hex-encoded signature of timestamp>"
}

Registry verifies by:

1. Fetching https://example.com/.well-known/mcp-registry
2. Validating timestamp is within 15 seconds
3. Verifying signature with the specified public key
4. Returning JWT token with com.example/* permissions

3. Publisher CLI Support

Would basically work same as DNS, but pass in --http-domain and --http-private-key. Docs should also provide an example of how to set it up, in the same way that we already do for DNS.