Extend spec to support multiple packages with different DIDs at the same domain #61
Description
Currently we have an enforced 1:1 relationship between package DIDs and domains, since we're disallowing having multiple DNS TXT records beginning with did= at _fair.example.com, and the _fair. subdomain is an enforced value. DNS supports multiple TXT records for a domain of course, but we can't since there's potential for ambiguity.
Bluesky somewhat handles this by using a .well-known endpoint, but their implementation expects 1:1 for their use case though GitHub has an implementation that gets around that to enable verifying Bluesky identities to GH users by remapping the .well-known endpoint to the user.
We probably want to use .well-known as well, as other ID methods are. For example:
| ID Method | Endpoint | Payload | Used By | ref |
|---|---|---|---|---|
| DID:PLC | .well-known/atproto-did |
plain text | ATProto | spec |
| DID:Web | .well-known/did.json |
JSON-LD or path | W3C | spec |
| DID:key | .well-known/did-configuration.json |
JSON-LD | DIF, W3C | spec1 spec2 |
Note that did:web specifically supports either a DID to represent the domain, or resolving multiple DIDs at that domain. GitHub will be doing this with DID:Web, which is also supported by AtProto. Unless the atproto-did endpoint is extended to support a path response like 'did.json`, we'll likely need to register our own .well-known endpoint with IANA, otherwise we'll have to rely on DID:Web if more than one package needs to be validated at a domain, which could be as simple as hosting both Git-Updater and Git-Updater-Lite on the same domain.