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.

Hey, I am a little confused about what is the intended scope of a XID, that is, what it is meant to identify? A device/resource? An entity? A user? Multiple users? A human? If we are fine with binding a XID to a specific device/resource, we could "just" use the OMEMO public key for it. Then binding the XID to a specific user in a cryptographically sane way would just be the same issue as doing that for OMEMO (which while not entirely solves, has a lot of work put into it) and there would be no additional identity or key management tasks. This reminds me of something I had in mind for reviving XEP-0174: adding a TXT key that carries a signature of other parts of the mDNS records, so that one can discover that a known OMEMO contact is nearby and send messages to them directly rather than through the server. Marvin On Tue, 2026-06-02 at 09:39 +0000, Daniel Gultsch wrote:

* Daniel Gultsch <daniel(a)gultsch.de> [2026-06-02 11:50]: Personally, I have VERY strong feelings about trying to shoehorn XMPP into a different line on Zooko's triangle. There are many other protocols out there that use cryptographic keys as identities and optimize routing, storage and E2EE on top of that, making the whole construct significantly more robust and secure than we ever could achieve with an overlay on top of XMPP. Is this XEP about adding a moderately-secure cryptographic proof to your account in order to make a XEP-0283 Moved possible if the server dies, or is this about having a strong cryptographic identity that can be used on multiple JIDs at the same time and would allow redirecting traffic from one to the other? I have a fear that it was designed for the former, but gives developers enough rope to be used for the latter. The former use case can probably be implemented with a small subset of this protocol, or even with a signed OMEMO record on the user's pubsub. Most of my following remarks are considering the latter use case. As written, there is no out-of-band mechanism to verify / exchange XIDs, so a malicious server can just create its own MitM XIDs for all accounts that try to publish one, and there is no easy way around that without OOB. That said, I'm with Marvin on strongly coupling a cryptographic identity (XID) with OMEMO (which would require a user identity as opposed to a device identity for being used as a XID, though). Detail notes on the XEP: §3 Overview I'm with Dave on creating a `xid.xmpp.org` domain for this purpose. §5.1 Publishing Publishing a signed record containing the XID, the JID and a timestamp (+ validity?) would prevent somebody from maliciously publishing foreign XIDs on their pubsub in order to try to circumvent routing or to exhaust resources. Validating the signed record can be done offline and does not require the Identity Challenge handshake at all. Routing the messages to the JID that has published the highest correctly signed timestamp value for a given XID would reduce the time window where a server admin can take over your identity (did I mention Zooko yet?). §5.2 Revoking I have a gut feeling that a revocation record should also contain the XID, the JID and the timestamp of revocation, in order to prevent malicious revocation by the server admin. OTOH, losing access to your private key would make the XID irrevocable in such a design. §6. Identity Challenge I fear this protocol is full of failure cases. Off the top of my head: How long do you wait until you consider a challenge as "timed out"? What do you do in that case? If you challenge the new XID of a user with a (now revoked) old XID, do you treat both as invalid until the new one is validated? What happens if user A publishes a new XID and multiple devices of user B send different challenges at the same time (with equal timestamp)? §8. Server Mapping What is this part supposed to achieve? As I read it, this is about the JID used on an individual c2s link between a server and its client, and allowing the client to use a XID instead of the authenticated JID. Given that the client knows both JID and XID, and the server knows the JID and could authenticate the XID, this is merely cosmetic? I can see benefits in a protocol that would allow XID-based routing (i.e a client sends a message to=XID and the local server would route it according to the JID that has been authenticated for that destination XID). However, such a protocol would impose a significant cryptographic responsibility upon the server, upon its s2s links (to other servers publishing XIDs), and would require a global XID routing table in order to work reliably. Ideally, in such a scenario, message payloads should be encrypted to the private key corresponding to the destination XID, in order to not leak any relevant content to somebody intercepting the routing process ;-) Georg