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

--===============6319794577237163306==
Content-Type: multipart/signed; boundary="nextPartM00UY9WDSCWEsAYSZDWJug";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPartM00UY9WDSCWEsAYSZDWJug
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Goffi <[email protected]>
To: XMPP Standards <[email protected]>
Date: Sun, 07 Jun 2026 19:08:33 +0200
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
MIME-Version: 1.0

Hi MSavoritias,

Le mercredi 3 juin 2026, 08:14:44 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99E=
urope centrale MSavoritias=20
via Standards a =C3=A9crit :
> I do not understand why the XEP is locked to OMEMO and also we roll our=20
> own identity scheme.

This protoXEP is not locked to OMEMO at all, why make you think that? OMEMO=
 is=20
only used for the optional  automatic private key synchronization feature, =
and=20
there is an alternative out-of-band QR code based method specified.

This not really a scheme, it's inspired from existing solution (Peer ID fro=
m=20
LibP2P), and it's simply using an existing widely used algorithm (Ed25519).=
=20
This spec simply adapt it to XMPP mechanisms, a thing we would have to do f=
or=20
any solution.

> What we can do instead is use a standard that is well documented and=20
> already exists for this Decentralized Identifiers=20

I admit that I was not aware of DIDs, but we could still have to adapt it t=
o=20
XMPP, and it's far more complicated to implement. The current proposal is=20
simple and use an algorithm that most client already use.

Also, the prefix byte is made to update to another method if necessary, so =
DIDs=20
or anything else could be used in the future.

> https://www.w3.org/TR/did-core/ this would give us:
>=20
> - decoupling of the verification of identity from any centralized entity=
=20
> and any encryption scheme

This spec does that. The prefix byte is there to not be dependent on curren=
t=20
encryption algorithm.
=20
> I understand that it supposedly strives to not depend on servers, but=20
> such a thing is not possible yet in xmpp due to DNS reliance. DIDs on=20
> the other hand can support multiple verification methods.

The main DNS reliance is in the JID. This proposal (again made to be easily=
=20
mappable on Peer ID which is widely used) is made to not have to rely on DN=
S.
=20
> - our own xmpp method to resolve things to
>=20
> - a standardized way to represent this and do discovery, not reinvent=20
> our own
>=20
> - multiple ways of authentication besides just xmpp pubsub things

This specification use PEP which is also what is used for OMEMO and OX, and=
=20
many other things. It's not reinventing anything. And other authentication=
=20
method are planned, notably out-of-band via QR Code.

PEP doesn't have to be the only way, it's just convenient because it has=20
everything needed.

Again, this is a protoXEP which would go as an experimental specification, =
made=20
to test implementation, and see if it works or not, and how it can be=20
improved. We are not discussing here a move to draft or final.


Best,
Goffi
--nextPartM00UY9WDSCWEsAYSZDWJug
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmolpZEACgkQKqmcu6xu
Kww88ggAiBXzR+IVu6VXL5Z0g710aK5WXirE9CujvpxrcG0SC6/8PzZuxeCnfazH
XZiV/42kSQD0jnnee7VsPy038HPbo0nsf0V+ux7Cj/4kY+DU6QQvF85jJERPg9yf
0RdIP69zMDC4lzvSO4JoTeIbw37DTHkoVEyUlATSLgje8tVqv16XnbT/J9n/EdaL
SAYQ2IMYZDyCiqL3L+NB4IXkbd2CkTuJsrULHK159MlYzgB+Z9K8wC4b73IZBw2k
rHvJq5GLdRpPZUy8qPuQ+5/c5y/xn51yRH/+oRW/G0ua9LXUbZLDeA54HqVcLFiX
LBOcy7WtTfBgmqW+69grA0N8iq4QJw==
=m7/3
-----END PGP SIGNATURE-----

--nextPartM00UY9WDSCWEsAYSZDWJug--




--===============6319794577237163306==
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]

--===============6319794577237163306==--