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

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

--nextPart1p6XJ3hnRgmccN7jxVIZeA
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 18:12:15 +0200
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
MIME-Version: 1.0

Hi,

Le mardi 2 juin 2026, 19:30:10 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99Euro=
pe centrale techmetx11 via Standards a =C3=A9crit :
> As it's written in the specs, I think the challenge protocol can be=20
> abused to leak a user's presence, because any device associated to the=20
> target user *MUST* send a message to the entity who requested the=20
> challenge, as soon as it receives it.

Indeed, that something to change, it should probably be answered only to pe=
ople with presence access.=20

>=20
> This would violate RFC 6121's guarantees to not leak the user's network=20
> availability to an entity who's not authorized to know about it.
>=20
> So, I'm wondering if we could instead have the identity verification be=20
> a secondary optional method of verification, and have something like a=20
> signature of the JID (signed by the XID) in the user's PEP node, that=20
> the user themself HAVE to re-sign once every so often, like a month or=20
> week to ensure it remains valid, so that old hosts cannot impersonate=20
> users with stale signatures.

That sounds like a good option.

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

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

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmolmF8ACgkQKqmcu6xu
KwyS1gf9Fl8x6ckMvklHNc8K0kHMWGL/s69CcGoqDjcO4/gjLZjCnvRLojXVfJH6
bx3og2HRSUEK0wFDH0mKwZ9gb980ZDa8U9ws2soZ3tFwwARVD7SH+fQYwnsFgrk8
QH0jFz7ErTORfgoCyrGOXKM+SsdRJmVKNUttLPGZX9is3ZJYhYDyKzjC6kTp990G
OhWvZyvOtx/c8C/Bah+LGzVnN2GPWEHx22pySlJcaiqlhU5KJcYiRmT7K/DCdm2J
H32nWaSyknq9nk1H34vG2NTosw9IEb5bBuQgdeJ4++BZF/Ohf0Qmb7oPGCfgEbcM
WbR/l6NEG5LBVLYYsuXEyWasBntfog==
=9Jik
-----END PGP SIGNATURE-----

--nextPart1p6XJ3hnRgmccN7jxVIZeA--




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

--===============0542420515332635229==--