Repeating my GH comment verbatim:
This generally looks good, and I support publication.
Blockers for advancement:
* I don't think you can use the internal TLD here. That's a free-for-all on
private networks, and in cases where a XID is confused with a JID (since
they share the same syntax) it could end up resolving to an actual XMPP
server. Does the syntax for a XID have to match that of a jid? If so, I'd
suggest that the XSF creates a
xid.xmpp.org domain for this purpose, with
zero'd SRV records.
* The challenge protocol is trivially MITMable. I suggest including the
source jid within the signed payload, and possibly signing the challenge
with the source XID too. This would mean that the challenge was mutual, and
mutually verifiable, though not end-to-end of course.
Four notes:
* I would strongly consider adding an expiry to the XID publication.
* I would also explicitly allow multiple XIDs - perhaps this is in place
already, I didn't notice it (but haven't exhaustively searched).
* I would also highly recommend examining PQ options (presumably KEM or
HPKI based) and also threshold cryptography might be interesting as well.
* By way of another approach worth examining, I'd suggest looking at Philip
Hallam-Baker's Mesh and its id service, callsigns:
https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01
Dave.