A field indicates how login data is used (login/password or equivalent data used for authentication). This field MUST have a 'var' attribute set to "auth_data", must be of type "list-single", and MUST have one of the following values:

• no_auth: the service does not require authentication.
• plain: the service receives the authentication data in plain text, meaning that it can access them and potentially copy them.
• hidden: the auth data are used but not seen by the service, because a technique to hide it (such as using a challenge to verify it) is used.
• restricted: no full authentication is used, instead a temporary access is given via a mechanism such as a token or OAuth, and the access is restricted in scope (i.e., what it is possible to do with the account) and time.

While clients can obviously already determine if they can use end-to-end encryption with a service, they have no way to know if a service acting as a proxy/gateway does send its data encrypted or not to third-party services. For instance, a client can send data end-to-end encrypted to a gateway using OMEMO Encryption (XEP-0384) XEP-0384: OMEMO Encryption <https://xmpp.org/extensions/xep-0384.html>., and then the gateway decrypts it and may send it in a totally different way, even unencrypted! This could give a false sense of security to the end-user, as it would appear as end-to-end encrypted in most clients (while in reality it's only e2ee between the client and the gateway/proxy).

To make the situation more clear, a data transmission field SHOULD be used, indicating how the data is transmitted from and to legacy services (this field doesn't specify how data is transmitted between the XMPP client and the service itself). The field MUST have a 'var' attribute set to "data_transmission", a type of "list-single". The value MUST be one of the following:

• plain: the data is sent without any encryption. It may be viewed by anybody with access to the network between the XMPP service and the destination.
• encrypted: the data is encrypted, but not end-to-end (e.g., with something such as TLS). It may be viewed by the XMPP service, the legacy service administrators, and the destination.
• e2e: the data is encrypted using an end-to-end algorithm, which SHOULD be specified with the encryption algorithm field (see below). It may be seen by the XMPP service and the destination.
• gre: Gateway Relayed Encryption is used: the data is encrypted by the XMPP client, passed by the XMPP service, and decrypted by the destination. Only the destination can see the data. When used, XMPP clients MUST ensure that GRE is actually used by the gateway.

When "encrypted" or "e2e" values are used in the previous field, the algorithm used SHOULD be specified with a field with a "var" attribute of "encryption_algorithm", with a type of "text-single", and with the human-readable name of the algorithm used (e.g., "TLSv1.3"). This is not necessary when "gre" is used, as this data is already known by the client in this case.

The data retention field indicates for how long data such as messages or files are stored on the service. The field MUST have a 'var' attribute set to "data_retention", be of type "text-single", and MUST indicate how long data is stored (at most) in hours. The following values have special meaning:

• 0: data is not stored and is used in transit in this service. Note that the data can still be stored by another service if this one is a proxy or a gateway (this can be checked with the service-tied form).
• infinite: data is stored without automatic purge. Depending on the service, the user may or may not handle data deletion themselves (this is specified with the "data_deletion" field, see below).
• unknown: data retention of this service cannot be determined. This can happen when the service is a gateway to another service, and data retention policy is not known.

The data deletion field indicates if a user can explicitly delete data on this service (via ad-hoc commands, pubsub semantics, or any easy-to-use method). The field MUST have a 'var' attribute set to "data_deletion", and be of type "boolean". It defaults to "false".

When data retention has a value other than "0", it is important to know how the data is encrypted at rest. This is exposed with a field which MUST have a 'var' attribute set to "encryption_at_rest", a type of "boolean", set to "true" when data is encrypted at rest. It defaults to "false".

A link to Terms of Service (ToS) can be specified with a field which MUST have a 'var' attribute set to "tos" and a type of "text-single". The value MUST be an URI to the ToS. The link can be an xmpp: URI (e.g., to a Pubsub item), an http(s) one, or using any kind of relevant scheme. As for other fields, if a proxy or a gateway is used, the ToS of the main scope applies to the service itself, while the ToS of legacy services use the identity-scoped forms.

Physical location of the data is very important information for the user: it determines the jurisdiction that applies, and it also indicates risks (e.g., natural disasters, geopolitical considerations, war zones, risks of spying, etc.).

There is already a specification to indicate the location of an XMPP entity: User Geolocation (XEP-0080) XEP-0080: User Geolocation <https://xmpp.org/extensions/xep-0080.html>., which should be used to indicate the location of the server via the pep node "http://jabber.org/protocol/geoloc" as explained in the specification. However, data may be in different locations at once (with a cluster of servers), in which case multiple items should be used in the pep node, one per data cluster. Item IDs may give a hint on the related data (e.g., cluster name), and XEP-0080's "description" field should be used to give details on this cluster and when/how data is stored there.

The "region" field of XEP-0080 SHOULD be duly specified, as it is information of major importance in the context of data policy: the law may differ from one administrative region to another within a given country.

A field indicating whether users can export all their data from the service. This field MUST have a 'var' attribute set to "data_export" and a type of "boolean". The default value is "false".

A field indicating who has access to user accounts or data. This field MUST have a 'var' attribute set to "access_policy", a type of "list-multi", and MUST include one or more of the following values:

• admins: Administrators of the service can access user data for operational or security purposes (e.g., account management, system maintenance).
• moderators: Moderators (e.g., for group chats or blog comments) can access user data within their moderation scope (e.g., content review, enforcement of community guidelines).
• organization_member: Any member of the organization owning the service can access user data (e.g., employees, contractors under the organization's control).
• government: Government or legal authorities can access user data under legal requirements (e.g., court orders, national security requests).
• advertisers: Third-party advertisers or ad networks can access user data for targeted advertising or analytics.
• partners: Business partners or affiliated services can access user data under contractual or collaborative agreements.
• none: No entity (other than the user) can access user data. If used, this value MUST be the only one selected.

A field indicating whether users can fully erase their account and associated data. This field MUST have a 'var' attribute set to "full_erasure" and a type of "boolean". The default value is "false".

A field indicating how often backups of user data are performed. This field MUST have a 'var' attribute set to "backup_frequency" and a type of "text-single". The value MUST specify the maximum frequency in hours between backups. A value of "0" indicates that no backups are performed. For example, a value of "24" indicates backups occur at most every 24 hours (i.e., daily). This field is RECOMMENDED for services storing user data.

A field indicating how long backups are retained. This field MUST have a 'var' attribute set to "backup_retention" and a type of "text-single". The value MUST specify the maximum duration in hours. The following special values can be used:

• 0: No backup is done.
• infinite: Backups are retained indefinitely.
• unknown: Backup retention policies are not publicly disclosed.

Human-readable information can be added with a field which MUST have a 'var' attribute set to "extra_info" and a type of "text-multi". This is useful to add extra details, precision, or any kind of information that end-users may need to know. The "xml:lang" attribute of the disco#info request can be used to determine the language of the description returned by the service.