As it's written in the specs, I think the challenge protocol can be abused to leak a user's presence, because any device associated to the target user *MUST* send a message to the entity who requested the challenge, as soon as it receives it. This would violate RFC 6121's guarantees to not leak the user's network availability to an entity who's not authorized to know about it. So, I'm wondering if we could instead have the identity verification be a secondary optional method of verification, and have something like a signature of the JID (signed by the XID) in the user's PEP node, that the user themself HAVE to re-sign once every so often, like a month or week to ensure it remains valid, so that old hosts cannot impersonate users with stale signatures. On 6/2/26 5:36 PM, Goffi wrote:
Le mardi 2 juin 2026, 17:06:27 heure d’été d’Europe centrale Marvin W. via Standards a écrit :
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? An entity (which can be a person, a bot, a group of human, whatever), but not a device.
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. OMEMO is per-device, it doesn't work here. It's also far more complicated to implement. OX could be used, but the key sharing mechanism is not specified anyway, and again it's more complicated to implement the whole thing (and it's not widespread). The current implementation is relatively easy for most clients, as Ed25519 is already used for OMEMO.
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. One of the main purpose of this proposal is to have a ID working for serverless, on which I'll be working soon. I've chosen something easily mappable to LibP2P's Peer ID.
Best, Goffi
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org