This specification documents a way for an XMPP server to report to other entities the relationship it has with a user on its domain.
In practice, a server may not trust all accounts equally. For example, if a server offers anonymous access or open registration, it may have very little trust in such users. Meanwhile a user account that was provisioned by a server administrator for an employee or a family member would naturally have a higher level of trust.
Even if a server alters its own behaviour based on how much it trusts a user account (such as preventing anonymous users from performing certain actions), other entities on the network have no way of knowing what trust to place in JIDs they have not encountered before - they can only judge the server as a whole.
This lack of insight can result in the negative actions (spam, abuse, etc.) by untrusted users on a domain causing the whole domain to be sanctioned by other servers.
This protocol will allow:
By providing this high-level information to other entities on the network, it allows them to make informed decisions about how to handle traffic at the account level rather than the server level.
For example, during a spam wave, a public MUC service may choose not to grant the 'participant' role by default to accounts that were very recently registered.
It aims to achieve this while preserving the privacy of the user themselves, and ensuring the user’s server has full discretion over what data to provide and to which entities it is provided.
This specification has similar goals to that of XEP-0275: Entity Reputation. It differs in the following ways:
Some of this information may also be discovered through XEP-0030: Service Discovery. This specification provides more detailed information than is currently exposed via service discovery, and it is also push-based, removing the need for recipients to separately query an account’s status while determining how to handle a stanza.
An affiliation is what we call the relationship that a user has with a service. Different affiliations imply different levels of trust. The affiliations defined in this specification are as follows:
It should be noted that these affiliations extend the account types defined in the Service Discovery Identities registry. Notably, this document adds an additional affiliation type: 'member'.
An affiliation element looks like this:
<info xmlns='urn:xmpp:raa:0'
affiliation='member'
since='2023-06-27T00:00:00Z'
trust='57' />The 'affiliation' attribute MUST be present, and the value MUST be one of the affiliations listed in the previous section. The 'since' attribute is optional, and contains a XEP-0082 DateTime profile string representing the date and time at which the account was approximately created. Please see the security considerations for advice on preserving privacy before exposing this information.
An entity may directly query for affiliation information about a JID.
<iq type="get" to="mr.nobody@service.example" from="example.com" id="123">
<query xmlns='urn:xmpp:raa:0'/>
</iq>The server SHOULD respond successfully with as much information as it permits the requesting entity to see:
<iq type="result" to="example.com" from="mr.nobody@service.example" id="123">
<info xmlns='urn:xmpp:raa:0' affiliation='registered' since='2023-06-27T00:00:00Z' trust='47'/>
</iq>Alternatively, the server MAY respond with a 'forbidden' error if it does not permit the requesting entity to view any information about account affiliations:
<iq type="error" to="example.com" from="mr.nobody@service.example" id="123">
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>Alternatively the <info/> element can be embedded into outgoing stanzas, such as presence or messages:
<presence to="user@example.com"
from="mr.nobody@service.example"
type="subscribe">
<info xmlns='urn:xmpp:raa:0'
affiliation='registered'
since='2023-06-27T00:00:00Z' />
</presence>The above stanza demonstrates a subscription request sent by a recently-registered user to a user on another server. When embedding, a server MUST announce which stanzas it supports embedding in. In such stanzas it MUST strip any existing <info/> elements that may have been sent by the client.
Receiving servers MUST only trust embedded <info/> elements when the origin server has announced support for them.
A server may exercise discretion over when it includes affiliation information. For example, it MAY choose to only reveal this information when sending stanzas to trusted servers, or withold it when sending stanzas to untrusted servers (the definition of trusted servers is beyond this specification - it may be implementation-specific or based on a protocol such as XEP-0267: Server Buddies).
Similarly, the information does not need to be included for every type of stanza. For example, a server SHOULD only include this information for stanzas that are sent to non-contacts. For example, messages and presence to JIDs that have not granted a presence subscription to the sender yet (i.e. absent from the sender’s roster, or with a subscription state of 'none' or 'from').
A server MAY also withold or reduce the information for certain affiliations - e.g. by reporting server administrators as simply 'member' if the server does not want to expose this information to the recipient.
The inclusion of the 'since' attribute is optional, but it SHOULD be included for accounts with the affiliation 'registered' accounts that were created within the past 30 days. It MAY be approximate (e.g. rounded to the nearest day) for performance or privacy reasons (the latter is discussed in the security considerations section).
The inclusion of the 'trust' attribute is optional, but it SHOULD be included for 'registered' accounts if 'since' is not included. That is, at least one of 'since' or 'trust' SHOULD be present for accounts with affiliation 'registered' to ensure a recipient has sufficient information to act on. The value of the 'trust' attribute MUST be an integer from 0 to 100 (inclusive). The value may be calculated by the server using any algorithm it deems appropriate. However, the same algorithm MUST be used for all users of the same affiliation, so that comparison between them is meaningful.
If a server supports this protocol and the query functionality, it MUST advertise the 'urn:xmpp:raa:0' feature in response to service discovery queries on its domain JID.
If the server also supports embedding affiliation into stanzas, it MUST also advertise the appropriate features from this list:
This specification describes a protocol that can be used to help enhance the security of the XMPP network. However, some considerations do apply.
If a server chooses to expose an account’s creation timestamp to untrusted entities, the reported value SHOULD be approximate - e.g. rounded to the day on which the account registered - to preserve privacy. Providing a value with a high precision may allow entities to correlate the account registration with other actions performed by the user, or determine a user’s likely time zone.
In particular, and in accordance with the security considerations of XEP-0082, the 'since' value MUST be reported in UTC.
The payloads described in this specification may be embedded by the server in stanzas originating from a user’s JID. This makes it trivial for clients to send spoofed <info/> elements if the server does not remove them. To protect against such spoofing:
None.
This document extends the 'Identity Categories and Types Registry' defined by XEP-0030 with the following addition to the 'account' category:
<type> <name>member</name> <desc>The user@host is a trusted member of the server - e.g. an account that was provisioned for known user</desc> <doc>XEP-xxxx</doc> </type>
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
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.
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>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
@report{wild2023raa,
title = {Reporting Account Affiliations},
author = {Wild, Matthew},
type = {XEP},
number = {0489},
version = {0.1.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0489.html},
date = {2023-06-28/2024-03-11},
}END