Re: Proposed XMPP Extension: XMPP Decentralized ID (XID)

--===============8567431390872537928==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="3pkrqvtbta2q5wit"
Content-Disposition: inline


--3pkrqvtbta2q5wit
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Standards] Proposed XMPP Extension: XMPP Decentralized ID (XID)
MIME-Version: 1.0

* Daniel Gultsch <[email protected]> [2026-06-02 11:50]:
> Title: XMPP Decentralized ID (XID)

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
=66rom 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:

=C2=A73 Overview

I'm with Dave on creating a `xid.xmpp.org` domain for this purpose.


=C2=A75.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?).


=C2=A75.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.


=C2=A76. 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)?


=C2=A78. 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=3DXID 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

--3pkrqvtbta2q5wit
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQTOVzSLalN7WGrfmR2zNNMIli/S3gUCah8QBgAKCRCzNNMIli/S
3rLIAKCTzLrbvvXkCz2PPt0gSX4RVxAUQwCfbh0vgW4fCmtRAygz/bVeuhv3TNs=
=HRMP
-----END PGP SIGNATURE-----

--3pkrqvtbta2q5wit--

--===============8567431390872537928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============8567431390872537928==--