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.
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-knownendpoint, 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-knownas well, as other ID methods are. For example:.well-known/atproto-did.well-known/did.json.well-known/did-configuration.jsonNote 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-didendpoint 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.