[Standards] Re: Proposed XMPP Extension: XMPP Decentralized ID (XID)

* 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