From 9436dd4fb1e62a136ca390b07848ae0a985c9b11 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Tue, 22 May 2018 19:18:52 +0200 Subject: [PATCH] ProtoXEP: Terms of Services --- inbox/tos.xml | 407 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 407 insertions(+) create mode 100644 inbox/tos.xml diff --git a/inbox/tos.xml b/inbox/tos.xml new file mode 100644 index 00000000..81ac0dd4 --- /dev/null +++ b/inbox/tos.xml @@ -0,0 +1,407 @@ + + +%ents; + + +]> + + +
+ Terms of Services + This specification provides an in-band, unauthenticated way to request the Terms of Service of an XMPP service. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0004 + XEP-0030 + XEP-0050 + XEP-0082 + + + + TOS + &jonaswielicki; + + 0.0.1 + 2018-05-22 + jwi +

First draft.

 + +
+ +

The XMPP ecosystem has no way to allow clients to display or refer the user to the &tos; and &pp; of any given server.

+ + +

The specification shall allow to satisfy the following requirements:

+
    +
  1. Provide a way to query a URL to a text version of the &tos; and &pp; of a service.
    2. +
  2. Provide an extensible way to convey key points of the &tos; and &pp; in a machine-readable format in-band.
    3. +
  3. Allow to query all information before authentication.
    4. +
  4. It should be possible to achieve the same effect with a client supporting &xep0050; and a web browser.
    5. +
+ + +

OPTIONAL.

+ + + +

A server which supports the &tos; protocol announces support via both stream features and &xep0030;.

+ + ... + + +]]> + + + ... + + ... + + +]]> + + +

The interaction with the Terms of Service is handled using &xep0050;.

+

To request the current Terms of Service and Opt-ins/Opt-outs, the client starts an Ad-Hoc command session with the 'urn:xmpp:tos:0' node at its server:

+ + + + + +]]> +

The client MUST include a <tos-support/> child in the initial request to inform the server that it fully supports the protocol. A server MAY reject the Ad-Hoc command from a client which does not fully support the protocol if the form would likely not render correctly or completely. In that case, a <not-acceptable/> type='cancel' error MUST be returned.

+

The server SHOULD use the value of xml:lang at the <command/> element to determine the language of returned texts.

+

If the server allows the request, it starts the command session and returns the payload:

+ + + + + + + + urn:xmpp:tos:0 + + + 0.1.0 + + + Terms of Use + + + + The Terms of Use for this service are defined by the following + documents. Please read them carefully. + + https://service.example/tos + https://service.example/privacy + + + Opt-ins + + + + + I have read and understood the Privacy Policy document + linked above. + + false + + + + + I allow analysis of my messages under Art. 9.1a for marketing + purposes (see Privacy Policy ยง12.3). + + false + + + + + Terms of Service + + + + + Privacy Policy + + + + + + + + + +]]> +

The command payload consists of two parts: The data form for legacy clients and additional opt-ins/opt-outs, and the machine-readable &tos; data. The machine-readable &tos; data is carried by a <tos/> element.

+

The <tos/> element has the following format:

+
+
version attribute
(exactly once) carries the opaque version identifier of the terms.
 +
<document/> element
(at least once) carries one of the possibly multiple documents which comprise the full terms of use (see below for details).
 +
<required-flags/> element
(at most once) carries a set of data form field var values which the user has to accept (set to true) in order to use the service.
 +
+

In the future, more children may be added to the <tos/> element. Conforming clients thus MUST ignore all children they do not understand.

+

The <document/> element has the following format:

+
+
<title/> element
(at most once) a human-readable title of the document in the language requested by the client.
 +
<source/> element
(at least once) a pair of url and MIME type. The same URL may be given multiple times with different MIME types. Duplicate MIME types MUST NOT occur.
 +
+

The <required-flags/> element contains zero or more <required-flag/> elements. The <required-flag/> elements have a var attribute which refers to one of the fields in the data form. Note that this is semantically different from <require/> in the data form (see &xep0004;)

+

The data form has the FORM_TYPE 'urn:xmpp:tos:0'. The fields 'urn:xmpp:tos:0#version' and 'urn:xmpp:tos:0#documents' are mandatory. If the value of the 'urn:xmpp:tos:0#version' data form field and the version attribute of the <tos/> element differ, the response is invalid.

+

The data form MAY contain arbitrary fields after the 'urn:xmpp:tos:0#documents' field.

+

A client supporting the &tos; protocol should remove the fields prefixed with 'urn:xmpp:tos:0#' from the form when displaying the form and use a richer representation obtained from the <tos/> element for the same data.

+

The 'urn:xmpp:tos:0#documents' MUST contain exactly one URL from each <document/> advertised in the <tos/> element. It is used to inform users of legacy clients of the terms.

+

The server MAY include <instruction/> and <title/> elements in the data form.

+

Once the user has filled out the form, the client submits it to the server:

+ + + + + urn:xmpp:tos:0 + + + 0.1.0 + + + Terms of Use + + + https://service.example/tos + https://service.example/privacy + + + Opt-ins + + + true + + + false + + + + +]]> +

The client does not include the <tos/> element in its response.

+

The server acknowledges the reception as usual:

+ + + The privacy settings have been updated. + + +]]> + + +

If the client did not include a <tos-support/> element in the initiating request and the server requires support for the &tos; protocol, it replies with an error:

+ + + + + Your client does not support the Terms of Service protocol. + Please review the Terms of Service online at + https://service.example/tos. + + + +]]> +

The server SHOULD include a human readable error text which MAY include a URL to a website where the user can agree to the terms and manage the opt-ins/opt-outs.

+ + +

If the user did not opt in into options required by the service, the service returns the original data to the client and adds an error note to the command:

+ + + + You have to confirm that you read and + understood the Privacy Policy document below. + + + + + + + urn:xmpp:tos:0 + + + 0.1.0 + + + Terms of Use + + + + The Terms of Use for this service are defined by the following + documents. Please read them carefully. + + https://service.example/tos + https://service.example/privacy + + ... + + + + Terms of Service + + + + ... + + + +]]> + + + + +

If a server updates its &tos;, it may inform its users with a notification. For this, a 'headline' <message/> is used:

+ + + We have updated our Terms of Service. Please refer to the current + version at https://service.example/tos. You have to review and agree to + the new version by the 25th of May 2018 to continue to use the service. + + + + + Terms of Service + + + + + Privacy Policy + + + + + 2018-05-25T00:00:00Z + +]]> +

The <body/> is included for clients not supporting the protocol. The user can then review the Terms of Service by themselves. In addition to the <body/>, a <tos-push/> element which contains the <tos/> element of the new terms and an optional <deadline/> element.

+

The <deadline/> element includes a &xep0082; DateTime value which indicates at which point in time the user must have agreed to the new &tos; to be allowed to continue to use the service.

+ + +

If a user does not agree to an update of the &tos;, a service may lock down the account. In this case, authentication is handled as normal. In the post-authentication stream features, the server then MUST include a <tos/> element with a <agreement-required/> child:

+ + ... + + + + +]]> +

If the <agreement-required/> element is included in the <tos/> stream feature, the client must first agree to the &tos; as described in Interact with Terms of Service.

+ +

If a client attempts to bind a resource before agreeing to the &tos;, the server rejects the request with a <policy-violation/> type 'cancel' error including an application defined condition of <agreement-required> in the namespace of this protocol.

+

A human readable error MUST be included for legacy clients. The human readable version SHOULD contain a URL to a web page where the user can agree to the &tos; without client support.

+ + + + + You need to agree to the current version of the Terms of + Service before continuing. + + + +]]> + + + + +
    +
  • A server which supports the protocol MUST announce support via both stream features and &xep0030; as described in Announcing support.
    • +
  • The version of the &tos; document as transferred in-band SHOULD NOT be shown to users and MUST be treated as opaque by entities. The version can be used to detect if a version of the document has already been seen by the user and skip displaying it in this case.
    • +
  • The version identifiers generated by servers MUST NOT be longer than 128 characters.
    • +
  • The version identifiers generated by servers MUST be unique for the domain of the server.
    • +
  • Entities MUST NOT compare two version numbers obtained from two different entities.
    • +
  • Servers MAY store notifications about &tos; changes in the users server-side archive.
    • +
  • Servers MAY re-send notifications about &tos; changes on each login of a client.
    • +
  • Servers SHOULD NOT both re-send notifications about &tos; changes on login and store them in the archive.
    • +
  • Servers MAY re-send notifications about &tos; changes periodically, but SHOULD NOT re-send them more often than once per day.
    • +
+ + +
    +
  • Implementations MUST ignore unknown children of the <tos/> element.
    • +
+ + +

OPTIONAL.

+ + +

The service SHOULD honor the xml:lang value of the &xep0050; <command/> in the initial request and choose its translations according to that.

+

When pushing a notification about a terms of service update, the service SHOULD use the stream-level xml:lang attribute to determine the locale used for the announcement.

+ + +

This specification allows another type of interaction before authentication. Server implementations MUST ensure that this protocol cannot be abused for pre-authentication attacks (e.g. Denial of Service).

+

Servers MUST NOT allow entities to query the &tos; of another server unless they are authenticated.

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol specifications.

+ +