Complete Domain Alias Validation feature

[toderash]

Feature is incomplete, misrepresenting an authenticity check.

Connect is reporting "Validated" for DID->Domain Aliases but is not actually validating them. Two examples:

If the domain for wp-crontrol.com were validated, we'd expect to see it in a txt record or at wp-crontrol.com/.well-known directory/atproto-did, which is 404, and the TXT record does not exist. Two ns lookup results for comparison:

brent@aragorn:~$ nslookup -type=txt _atproto.wp-crontrol.com
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find _atproto.wp-crontrol.com: NXDOMAIN

brent@aragorn:~$ nslookup -type=txt _atproto.toderash.net
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
_atproto.toderash.net	text = "did=did:plc:aeun74r34thcit5ixvmwaqza"

What Connect is doing is taking the publisher's attestation of the domain alias and reporting it as verified without actually doing any verification steps.

The PLC server reports the domain alias (aka) for wp-crontrol, but not for git-updater, which isn't set.
https://web.plc.directory/did/did:plc:kjnlj6j6hvasaxc6rchd3pnu
https://web.plc.directory/did/did:plc:afjf7gsjzsqmgc7dlhb553mv

To verify that the domain is associated with the DID, this check should be performed on both sides, not just the from the DID document.

[afragen]

How does one actually enter this data?

nslookup -type=txt _fair.git-updater.com
Server:		100.100.100.100
Address:	100.100.100.100#53

Non-authoritative answer:
_fair.git-updater.com	text = "did=did:plc:afjf7gsjzsqmgc7dlhb553mv"

[toderash]

@afragen that's CLI on my local machine - if you do nslookup -type=txt _fair.git-updater.com on the command line, the rest is the reply you should get, like this:

$ nslookup -type=txt _fair.git-updater.com
x
x
Non-authoritative answer:
_fair.git-updater.com	text = "did=did:plc:afjf7gsjzsqmgc7dlhb553mv"

(The 'x' parts will vary, depending on your local dns setup.) Here I can see that the DID is properly set in your DNS.

The missing piece is that the DID document for GU doesn't have a value set for alsoKnownAs, which should be set to fair://git-updater.com. That can be set from Beacon when you register the DID, but I'm not sure about editing it after the fact, as I haven't actually run Beacon myself. Not sure if @namithj has a function yet in https://github.com/fairpm/did-manager to update the DID document. By whatever method, this is the step needed to verify the domain alias.

Also noted I should of course have checked DNS for _fair.domain rather than _atproto.domain so that's my bad, but you caught that in your question.

Issue Update

So while digging a bit deeper for this, I realized I had missed where the DNS lookup is actually done in Beacon already (I missed a step in following the abstracted code), so I've removed the "Bug" type and labelled it "Discussion", so this ticket is no longer actionable just yet.

What we do need to address is the the need for two DIDs to exist on the same name for different packages. For example, _fair.git-updater.com could have two DNS TXT records, but if they were both limited to the "did=xyz" content, we have potential room for confusion, and Connect explicitly disallows that whe checking.

How Bluesky deals with this is by also supporting the use of a .well-known endpoint, which is how I think we should do it as well, but we'll need to document how that should work and apply to IANA to make it official. As it stands, we've got each package tied to a domain in a strict 1:1 relationship.

[afragen]

There is no setting in Beacon for AlsoKnownAs.

[toderash]

Well, that answers that. 🤦‍♂️

Tagging @namithj on this, as it'll need to be part of DID Manager.

@johnbillion, how did you update your DID document for the alsoKnownAs value? Maybe shoot Andy a DM.

[namithj]

Ideally We should stop adding new protocol related features to the plugins and do it exclusively via DID Manager and then use it as a dependency in the plugins. That would ensure consistent behaviour across everything as well as having a centralised place for us to make protocol related additions and changes.

[johnbillion]

This feature in FAIR Connect validates a _fairpm TXT record, not an _atproto TXT record, which is a different thing. The correct query that shows the valid TXT record for wp-crontrol.com is:

nslookup -type=txt _fairpm.wp-crontrol.com

I'm managing my DID documents using my fair-tools package:

fair-tools did aka add --did did:plc:kjnlj6j6hvasaxc6rchd3pnu --url fair://wp-crontrol.com