XEP-xxxx: XMPP Decentralized ID (XID)

1. Introduction¶

Identification on XMPP is done with the Jabber ID (JID), which is an email-like, human-friendly identifier. While handy, JID is usually tied to a Domain Name Server, which makes it difficult to change server (while Moved (XEP-0283) [1] helps, it needs the server to be available and cooperating), and which is not usable in a serverless environment.

XMPP Decentralized ID (XID) uses a simple mechanism based on cryptographic signature to have an entity identity independent of any central organization or component. It is designed to be simple to implement and use, and to stay compatible with normal JID.

XID can be used to implement the "cryptographic verification" mentioned in Moved (XEP-0283) [1] with the benefit that the old server doesn't need to be online or cooperating (thus it will work if the server is down or actively blocking migrations). It can also be used in a serverless environment. XID allows keeping track of entities, so if a user's contacts change server, or communicate in a serverless configuration, a client can use it to verify who it is talking to, and to keep all existing cached data (message history, vcard, avatars, etc.). XID could also be used to sign any external data to associate it with the XMPP entity, like a document or an image, or metadata (e.g., to associate a resource like a website with an XMPP entity).

2. Requirements¶

The design goals of this XEP are:

• Be independent of any central authority or component.
• Be as simple as possible to implement, re-using existing components when possible.
• Be usable in serverless configurations.
• Be future proof by allowing to change cryptographic algorithms.

3. Overview¶

A XID is derived from a cryptographic signature. It currently uses Ed25519 (which is already used for OMEMO Encryption (XEP-0384) [2] so most clients have an implementation already). The private key is shared between devices of the entity, and the public key is used to generate the ID (printed as a hex string in lowercase, with a prefix byte). The ID can then be used as a JID in the "<ID>@id.internal" form (this is this form that we call a "XID").

The XID is published on a well-known PEP node ('urn:xmpp:xid'), and private key synchronization is done automatically via end-to-end encrypted messages (via OMEMO Encryption (XEP-0384) [2] or OpenPGP for XMPP Instant Messaging (XEP-0374) [3]) or another means. XID can also be revoked via a PEP node.

4. XID Generation and JID Mapping¶

To generate a XID, an entity must generate a public key and a private key. The former will be used to generate the ID, and the latter must be shared between devices of the entity, and kept secret otherwise (see below for private key synchronization).

The private key can be used to sign any kind of file or document, even outside of XMPP, and the corresponding public key can be used to verify those signatures. This allows an entity to associate external data with its XID identity independently of any XMPP communication.

To generate the ID, the public key is converted to a hex string (which MUST be lowercase), then the prefix byte "00" is prepended to indicate that Ed25519 is used. A JID is built by using this ID as node part, and "id.internal" as domain part.

5. Publishing and Revoking XID¶

<iq type='set'
    from='juliet@capulet.lit/balcony'
    to='juliet@capulet.lit'
    id='xidpub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:xid'>
      <item id='current'>
        <xid xmlns='urn:xmpp:xid:0'
             created='2026-05-27T14:30:00Z'>
          0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal
        </xid>
      </item>
    </publish>
  </pubsub>
</iq>

<iq type='set'
    from='juliet@capulet.lit/balcony'
    to='juliet@capulet.lit'
    id='xidrev1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <retract node='urn:xmpp:xid'>
      <item id='current'/>
    </retract>
  </pubsub>
</iq>

<iq type='set'
    from='juliet@capulet.lit/balcony'
    to='juliet@capulet.lit'
    id='xidrev2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:xid:revoked'>
      <item id='0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8'>
        <revoked xmlns='urn:xmpp:xid:0'
                 created='2026-05-27T14:30:00Z'
                 revoked='2026-05-30T09:15:00Z'>
          0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal
        </revoked>
      </item>
    </publish>
  </pubsub>
</iq>

6. Identity Challenge¶

To verify that an entity is allowed to use the XID, an XMPP entity can send a <message/> stanza with the default type ("chat") to the bare JID of the entity to verify. This stanza MUST have a <challenge/> element qualified by the 'urn:xmpp:xid:0' namespace. The <challenge/> MUST have a 'xid' attribute with the XID to verify, a 'timestamp' attribute with a DateTime value as specified in XMPP Date and Time Profiles (XEP-0082) [5] indicating when the challenge was issued, and MUST have a nonce for its content (i.e., a cryptographically strong random number used only once). The nonce MUST be encoded as a hex string (lowercase).

When the <challenge/> element is received by any of the devices having the private key corresponding to this XID, it MUST sign the requested nonce and send a message to the entity requesting the challenge with a <response/> element qualified by the 'urn:xmpp:xid:0' namespace. The <response/> element MUST have a 'xid' attribute with the XID being verified, a 'timestamp' attribute matching the 'timestamp' from the <challenge/> element, and MUST use the hex-encoded signature of the nonce as content. The entity verifier MUST then check that the signature is correct for this nonce and that the public key corresponds to the XID (i.e., the localpart of the JID from which the algorithm prefix byte has been stripped).

Notes:

1. <message/> is used here instead of <iq/> because it lets request the bare entity and it can be replied asynchronously if no device is connected at the moment of the challenge.
2. Because <message/> is used, several devices may receive the challenge thanks to Message Carbons (XEP-0280) [6]. If a device sees that the <response/> element has already been sent by another device, it SHOULD NOT send this element itself. However, the verifying entity MUST expect to receive several <response/> elements. Only the first one received MUST be verified, following ones MUST be ignored.

<message type='chat'
         from='romeo@montague.lit/orchard'
         to='juliet@capulet.lit'>
  <challenge xmlns='urn:xmpp:xid:0'
             xid='0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal'
             timestamp='2026-05-30T10:15:30Z'>
    a3f2c8b1e9d74560
  </challenge>
</message>

<message type='chat'
         from='juliet@capulet.lit/balcony'
         to='romeo@montague.lit/orchard'>
  <response xmlns='urn:xmpp:xid:0'
            xid='0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal'
            timestamp='2026-05-30T10:15:30Z'>
    7f2be0038e2f62b4ab6688440e07cd5939549feb810fc2514a26282d35056d3aea60c8c102dd3dbce678b520ca3622fbdb53b402cf7ca7f97d75ec23c29bc00d
  </response>
</message>

7. Private Key Synchronization¶

Devices may use several ways to share private keys. Two methods are described below: QR Code exchange and automatic synchronization.

xmpp:<public_key>@id.internal?;xid-private=<private_key>;xid-created=<timestamp>

xmpp:0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal?;xid-private=000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f;xid-created=2026-05-27T14:30:00Z

<message type='chat'
         from='juliet@capulet.lit/tablet'
         to='juliet@capulet.lit'>
  <encrypted xmlns='urn:xmpp:omemo:2'>
    <header sid='12345'>
      <keys jid='juliet@capulet.lit'>
        <key rid='67890'><!-- base64 key --></key>
        <key rid='09876'><!-- base64 key --></key>
      </keys>
    </header>
    <payload>
      <!-- The payload is normally encrypted and unreadable;
        we show it here in plaintext to illustrate the protocol -->
      <envelope xmlns='urn:xmpp:sce:1'>
        <content>
          <private-key-request xmlns='urn:xmpp:xid:0'
                               xid='0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal'/>
        </content>
        <rpad>...</rpad>
        <from jid='juliet@capulet.lit/tablet'/>
      </envelope>
    </payload>
  </encrypted>
</message>

<message type='chat'
         from='juliet@capulet.lit/phone'
         to='juliet@capulet.lit'>
  <encrypted xmlns='urn:xmpp:omemo:2'>
    <header sid='67890'>
      <keys jid='juliet@capulet.lit'>
        <key rid='12345'><!-- base64 key --></key>
        <key rid='09876'><!-- base64 key --></key>
      </keys>
    </header>
    <payload>
      <!-- The payload is normally encrypted and unreadable;
        we show it here in plaintext to illustrate the protocol -->
      <envelope xmlns='urn:xmpp:sce:1'>
        <content>
          <private-key xmlns='urn:xmpp:xid:0'
                       xid='0003a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8@id.internal'>
            000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
          </private-key>
        </content>
        <rpad>...</rpad>
        <from jid='juliet@capulet.lit/phone'/>
      </envelope>
    </payload>
  </encrypted>
</message>

8. Server Mapping¶

A server MAY support XID to and from JID mapping: if it has proven the identity and association between a JID and a XID (e.g., via the Identity Challenge mechanism), and an entity is using a XID in its 'from' attribute, it MUST convert any incoming stanza where the XID is used in the 'from' attribute to the corresponding JID, and it MUST convert any stanza sent to the corresponding entity by replacing the JID used in the 'to' attribute with the corresponding XID. A server that supports this feature MUST advertise it by including the 'urn:xmpp:xid:server-mapping:0' discovery feature in response to a Service Discovery (XEP-0030) [8] information request.

9. Business Rules¶

• In a serverless environment, if there is no mechanism to handle PEP service without a server available, the XID should be published by any other practical means available in the configuration. How this is done is dependent of the set-up and beyond the scope of this specification.
• The same XID can be associated with one or more DNS-based JIDs. This happens naturally when the same XID is published on the 'urn:xmpp:xid' PEP node of multiple accounts; for example after a server move, or to explicitly link several accounts belonging to the same entity (e.g., work and personal, or several personal accounts on different servers). How a client manages sharing a single XID across multiple accounts is beyond the scope of this specification and is left to client-specific implementation or other XEPs (e.g., Moved (XEP-0283) [1]).
• If Private Key Synchronization is used, the XMPP client SHOULD show a notification indicating that the XID private key has been shared, and SHOULD show which devices it has been shared with (if possible, including information such as the device type (e.g., "phone", "web") and the client used on each device). This allows users to identify which device it is, and detect more easily if it is one of their own, or a suspicious one.
• If Atomically Compare-And-Publish PubSub Items (XEP-0395) [9] is supported by the PEP service, it SHOULD be used to prevent accidental overwriting of the current XID in case of a race condition.
• XID MAY be used in place of DNS-based JIDs to identify users (e.g., for the publisher attribute in Publish-Subscribe (XEP-0060) [10]). That way, if the user changes server (including the pubsub service in this case), the items stay valid.

10. Discovering Support¶

If a client supports XID, it MUST advertise it by including the 'urn:xmpp:xid:0' discovery feature in response to a Service Discovery (XEP-0030) [8] information request:

<iq type='get'
    from='juliet@capulet.lit/balcony'
    to='romeo@montague.lit/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:xid:0'/>
    ...
  </query>
</iq>

A server that supports XID to and from JID mapping (see Server Mapping) MUST advertise the 'urn:xmpp:xid:server-mapping:0' discovery feature:

<iq type='result'
    from='capulet.lit'
    to='juliet@capulet.lit/balcony'
    id='disco2'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:xid:server-mapping:0'/>
    ...
  </query>
</iq>

11. Accessibility Considerations¶

This specification does not define any user interface elements and therefore has no accessibility considerations.

12. Privacy Considerations¶

XID is designed to be independent of DNS-based identifiers, which can help reduce correlation by third parties. However, the XID itself is a stable identifier that can be used to track entities across different JIDs and servers. Entities should be aware that publishing their XID (especially with an "open" access model) makes this association publicly discoverable, and could be used for any kind of undesired tracking (advertisement, profiling, etc.).

13. Security Considerations¶

Many OMEMO implementations use TOFU authentication scheme by default, or similar ones. If user devices have not been manually and correctly verified out of band, there is a risk that a malicious entity has set a compromised key (e.g., if the server is compromised). Among the problems involved (end-to-end encryption compromised), that would mean that Private Key Synchronization would potentially leak the private key to compromised devices. This is a problem of balance between UX and security.

Challenge/response pairs are protected against replay by the nonce mechanism. A verifying entity MUST NOT accept a response to the same nonce more than once.

14. IANA Considerations¶

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

15. XMPP Registrar Considerations¶

The namespaces 'urn:xmpp:xid:0' and 'urn:xmpp:xid:server-mapping:0' should be included in the registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).

The well-known PEP nodes 'urn:xmpp:xid' and 'urn:xmpp:xid:revoked' should be included in the registry of nodes for service discovery and publish-subscribe (see <https://xmpp.org/registrar/nodes.html>).

16. Acknowledgements¶

This work has been done for the Serverless and Metadata Reduction for XMPP project. Many thanks to NLNet foundation and NGI Zero Core for funding the work on this specification.

17. XML Schema¶

TODO

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2026-06-01

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0060, XEP-0082, XEP-0163, XEP-0280

Supersedes

None

Superseded By

None

Short Name

xid

This document in other formats: XML  PDF

Appendix B: Author Information¶

Jérôme Poisson

Email

goffi@goffi.org

JabberID

goffi@jabber.fr

URI

https://www.goffi.org

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2026-06-01)¶

   First draft.

   jp

Appendix I: Bib(La)TeX Entry

@report{poisson2026xid,
  title = {XMPP Decentralized ID (XID)},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2026-06-01/2026-06-01},
}

END