mirror of https://github.com/moparisthebest/xeps
ProtoXEP: Terms of Services
This commit is contained in:
Jonas Wielicki
parent
76e9cf0d58
commit
9436dd4fb1
|
|
@ -0,0 +1,407 @@
|
|||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
<!ENTITY tos "Terms of Service">
|
||||
<!ENTITY pp "Privacy Policy">
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Terms of Services</title>
|
||||
<abstract>This specification provides an in-band, unauthenticated way to request the Terms of Service of an XMPP service.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0004</spec>
|
||||
<spec>XEP-0030</spec>
|
||||
<spec>XEP-0050</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>TOS</shortname>
|
||||
&jonaswielicki;
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2018-05-22</date>
|
||||
<initials>jwi</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>The XMPP ecosystem has no way to allow clients to display or refer the user to the &tos; and &pp; of any given server.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>The specification shall allow to satisfy the following requirements:</p>
|
||||
<ol>
|
||||
<li>Provide a way to query a URL to a text version of the &tos; and &pp; of a service.</li>
|
||||
<li>Provide an extensible way to convey key points of the &tos; and &pp; in a machine-readable format in-band.</li>
|
||||
<li>Allow to query all information before authentication.</li>
|
||||
<li>It should be possible to achieve the same effect with a client supporting &xep0050; and a web browser.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<p>OPTIONAL.</p>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Announcing support' anchor='usecase-announce'>
|
||||
<p>A server which supports the &tos; protocol announces support via both stream features and &xep0030;.</p>
|
||||
<example caption='Stream feature which indicates support'><![CDATA[
|
||||
<stream:features>
|
||||
...
|
||||
<tos xmlns='urn:xmpp:tos:0'/>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
<example caption='XEP-0030 disco#info feature to indicate support'><![CDATA[
|
||||
<iq type='result'
|
||||
from='service.example'
|
||||
to='requester@service.example'
|
||||
id='req1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:tos:0'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Interact with Terms of Service' anchor='usecase-interaction'>
|
||||
<p>The interaction with the Terms of Service is handled using &xep0050;.</p>
|
||||
<p>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:</p>
|
||||
<example caption='Client initiates Ad-Hoc Command session'><![CDATA[
|
||||
<iq type='set'
|
||||
from='requester@service.example'
|
||||
to='service.example'
|
||||
id='cmd1'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='urn:xmpp:tos:0'
|
||||
action='execute'>
|
||||
<tos-support xmlns='urn:xmpp:tos:0'/>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
<p>The server SHOULD use the value of xml:lang at the <command/> element to determine the language of returned texts.</p>
|
||||
<p>If the server allows the request, it starts the command session and returns the payload:</p>
|
||||
<example caption='Server returns Terms of Service payload'><![CDATA[
|
||||
<iq type='result'
|
||||
to='requester@service.example'
|
||||
from='service.example'
|
||||
id='cmd1'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='urn:xmpp:tos:0'
|
||||
sessionid='dlW81nadFUAS7VSWOOJ4e1J1'
|
||||
status='executing'>
|
||||
<actions execute='complete'>
|
||||
<complete/>
|
||||
</actions>
|
||||
<x xmlns='jabber:iq:data'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:tos:0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#version' type='hidden'>
|
||||
<value>0.1.0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents-header' type='fixed'>
|
||||
<value>Terms of Use</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents' type='text-multi'>
|
||||
<desc>
|
||||
The Terms of Use for this service are defined by the following
|
||||
documents. Please read them carefully.
|
||||
</desc>
|
||||
<value>https://service.example/tos</value>
|
||||
<value>https://service.example/privacy</value>
|
||||
</field>
|
||||
<field type='fixed'>
|
||||
<value>Opt-ins</value>
|
||||
</field>
|
||||
<field var='https://service.example/privacy' type='boolean'>
|
||||
<required/>
|
||||
<desc>
|
||||
I have read and understood the Privacy Policy document
|
||||
linked above.
|
||||
</desc>
|
||||
<value>false</value>
|
||||
</field>
|
||||
<field var='https://service.example/privacy#12.3-marketing' type='boolean'>
|
||||
<required/>
|
||||
<desc>
|
||||
I allow analysis of my messages under Art. 9.1a for marketing
|
||||
purposes (see Privacy Policy §12.3).
|
||||
</desc>
|
||||
<value>false</value>
|
||||
</field>
|
||||
</x>
|
||||
<tos xmlns='urn:xmpp:tos:0' version='0.1.0'>
|
||||
<document>
|
||||
<title>Terms of Service</title>
|
||||
<source url='https://service.example/tos' type='text/html' />
|
||||
<source url='https://service.example/tos.txt' type='text/plain' />
|
||||
</document>
|
||||
<document>
|
||||
<title>Privacy Policy</title>
|
||||
<source url='https://service.example/privacy' type='text/html' />
|
||||
<source url='https://service.example/privacy.txt' type='text/plain' />
|
||||
</document>
|
||||
<required-flags>
|
||||
<required-flag var='https://service.example/privacy'/>
|
||||
</required-flags>
|
||||
</tos>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
<p>The <tos/> element has the following format:</p>
|
||||
<dl>
|
||||
<di><dt>version attribute</dt><dd>(exactly once) carries the opaque version identifier of the terms.</dd></di>
|
||||
<di><dt><document/> element</dt><dd>(at least once) carries one of the possibly multiple documents which comprise the full terms of use (see below for details).</dd></di>
|
||||
<di><dt><required-flags/> element</dt><dd>(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.</dd></di>
|
||||
</dl>
|
||||
<p>In the future, more children may be added to the <tos/> element. Conforming clients thus MUST ignore all children they do not understand.</p>
|
||||
<p>The <document/> element has the following format:</p>
|
||||
<dl>
|
||||
<di><dt><title/> element</dt><dd>(at most once) a human-readable title of the document in the language requested by the client.</dd></di>
|
||||
<di><dt><source/> element</dt><dd>(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.</dd></di>
|
||||
</dl>
|
||||
<p>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;)</p>
|
||||
<p>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.</p>
|
||||
<p>The data form MAY contain arbitrary fields after the 'urn:xmpp:tos:0#documents' field.</p>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<p>The server MAY include <instruction/> and <title/> elements in the data form.</p>
|
||||
<p>Once the user has filled out the form, the client submits it to the server:</p>
|
||||
<example caption='Client submits filled-out form'><![CDATA[
|
||||
<iq type='set'
|
||||
to='service.example'
|
||||
from='requester@service.example'
|
||||
id='cmd2'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='urn:xmpp:tos:0'
|
||||
sessionid='dlW81nadFUAS7VSWOOJ4e1J1'
|
||||
action='complete'>
|
||||
<x xmlns='jabber:iq:data'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:tos:0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#version' type='hidden'>
|
||||
<value>0.1.0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents-header' type='fixed'>
|
||||
<value>Terms of Use</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents' type='text-multi'>
|
||||
<value>https://service.example/tos</value>
|
||||
<value>https://service.example/privacy</value>
|
||||
</field>
|
||||
<field type='fixed'>
|
||||
<value>Opt-ins</value>
|
||||
</field>
|
||||
<field var='https://service.example/privacy' type='boolean'>
|
||||
<value>true</value>
|
||||
</field>
|
||||
<field var='https://service.example/privacy#12.3-marketing' type='boolean'>
|
||||
<value>false</value>
|
||||
</field>
|
||||
</x>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The client does not include the <tos/> element in its response.</p>
|
||||
<p>The server acknowledges the reception as usual:</p>
|
||||
<example caption='Server acknowledges submission'><![CDATA[
|
||||
<iq type='result'
|
||||
to='requester@service.example'
|
||||
from='service.example'
|
||||
id='cmd2'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='urn:xmpp:tos:0'
|
||||
sessionid='dlW81nadFUAS7VSWOOJ4e1J1'
|
||||
status='completed'>
|
||||
<note type='info'>The privacy settings have been updated.</note>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
<section3 topic='Error cases' anchor='usecase-interaction-errors'>
|
||||
<section4 topic='Protocol support required' anchor='usecase-interaction-error-support-required'>
|
||||
<p>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:</p>
|
||||
<example caption='Server requests request because of lack of protocol support'><![CDATA[
|
||||
<iq type='error'
|
||||
from='service.example'
|
||||
to='requester@service.example'
|
||||
id='cmd1'>
|
||||
<error type='cancel'>
|
||||
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
|
||||
Your client does not support the Terms of Service protocol.
|
||||
Please review the Terms of Service online at
|
||||
https://service.example/tos.
|
||||
</text>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
</section4>
|
||||
<section4 topic='Required opt-ins not selected' anchor='usecase-interaction-error-required-flag-unset'>
|
||||
<p>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:</p>
|
||||
<example caption='Server rejects submission because required options have not been selected'><![CDATA[
|
||||
<iq type='result'
|
||||
to='requester@service.example'
|
||||
from='service.example'
|
||||
id='cmd2'
|
||||
xml:lang='en'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='urn:xmpp:tos:0'
|
||||
sessionid='dlW81nadFUAS7VSWOOJ4e1J1'
|
||||
status='executing'>
|
||||
<note type='error'>
|
||||
You have to confirm that you read and
|
||||
understood the Privacy Policy document below.
|
||||
</note>
|
||||
<actions execute='complete'>
|
||||
<complete/>
|
||||
</actions>
|
||||
<x xmlns='jabber:iq:data'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>urn:xmpp:tos:0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#version' type='hidden'>
|
||||
<value>0.1.0</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents-header' type='fixed'>
|
||||
<value>Terms of Use</value>
|
||||
</field>
|
||||
<field var='urn:xmpp:tos:0#documents' type='text-multi'>
|
||||
<desc>
|
||||
The Terms of Use for this service are defined by the following
|
||||
documents. Please read them carefully.
|
||||
</desc>
|
||||
<value>https://service.example/tos</value>
|
||||
<value>https://service.example/privacy</value>
|
||||
</field>
|
||||
...
|
||||
</x>
|
||||
<tos xmlns='urn:xmpp:tos:0' version='0.1.0'>
|
||||
<document>
|
||||
<title>Terms of Service</title>
|
||||
<source url='https://service.example/tos' type='text/html' />
|
||||
<source url='https://service.example/tos.txt' type='text/plain' />
|
||||
</document>
|
||||
...
|
||||
</tos>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section4>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Notify entity about new policies' anchor='usecase-notify'>
|
||||
<p>If a server updates its &tos;, it may inform its users with a notification. For this, a 'headline' <message/> is used:</p>
|
||||
<example caption='Server notifies user about policy update'><![CDATA[
|
||||
<message type='headline'
|
||||
from='service.example'
|
||||
to='user@service.example'>
|
||||
<body>
|
||||
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.
|
||||
</body>
|
||||
<tos-push xmlns='urn:xmpp:tos:0'>
|
||||
<tos xmlns='urn:xmpp:tos:0' version='0.2.0'>
|
||||
<document>
|
||||
<title>Terms of Service</title>
|
||||
<source url='https://service.example/tos-0.2.0' type='text/html' />
|
||||
<source url='https://service.example/tos-0.2.0.txt' type='text/plain' />
|
||||
</document>
|
||||
<document>
|
||||
<title>Privacy Policy</title>
|
||||
<source url='https://service.example/privacy-0.2.0'
|
||||
type='text/html' />
|
||||
<source url='https://service.example/privacy-0.2.0.txt'
|
||||
type='text/plain' />
|
||||
</document>
|
||||
</tos>
|
||||
<deadline>2018-05-25T00:00:00Z</deadline>
|
||||
</tos-push>
|
||||
</iq>]]></example>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
<section2 topic='Inform client about Terms of Service expiry after authentication' anchor='usecase-expired'>
|
||||
<p>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:</p>
|
||||
<example caption='Stream feature which indicates requirement to agree'><![CDATA[
|
||||
<stream:features>
|
||||
...
|
||||
<tos xmlns='urn:xmpp:tos:0'>
|
||||
<agreement-required/>
|
||||
</tos>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
<p>If the <agreement-required/> element is included in the <tos/> stream feature, the client must first agree to the &tos; as described in <link url='#usecase-interaction'>Interact with Terms of Service</link>.</p>
|
||||
<section3 topic='Reject bind attempt before agreement' anchor='usecase-expired-reject-bind'>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<example caption='Server rejects attempt to bind to a resource'><![CDATA[
|
||||
<iq type='error'
|
||||
id='bind'>
|
||||
<error type='cancel'>
|
||||
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='en'>
|
||||
You need to agree to the current version of the Terms of
|
||||
Service before continuing.
|
||||
</text>
|
||||
<agreement-required xmlns='urn:xmpp:tos:0'/>
|
||||
</error>
|
||||
</iq>]]></example>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Business Rules' anchor='rules'>
|
||||
<ul>
|
||||
<li>A server which supports the protocol MUST announce support via both stream features and &xep0030; as described in <link url='#usecase-announce'>Announcing support</link>.</li>
|
||||
<li>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.</li>
|
||||
<li>The version identifiers generated by servers MUST NOT be longer than 128 characters.</li>
|
||||
<li>The version identifiers generated by servers MUST be unique for the domain of the server.</li>
|
||||
<li>Entities MUST NOT compare two version numbers obtained from two different entities.</li>
|
||||
<li>Servers MAY store notifications about &tos; changes in the users server-side archive.</li>
|
||||
<li>Servers MAY re-send notifications about &tos; changes on each login of a client.</li>
|
||||
<li>Servers SHOULD NOT both re-send notifications about &tos; changes on login and store them in the archive.</li>
|
||||
<li>Servers MAY re-send notifications about &tos; changes periodically, but SHOULD NOT re-send them more often than once per day.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<ul>
|
||||
<li>Implementations MUST ignore unknown children of the <tos/> element.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Accessibility Considerations' anchor='access'>
|
||||
<p>OPTIONAL.</p>
|
||||
</section1>
|
||||
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
||||
<p>The service SHOULD honor the xml:lang value of the &xep0050; <command/> in the initial request and choose its translations according to that.</p>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>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).</p>
|
||||
<p>Servers MUST NOT allow entities to query the &tos; of another server unless they are authenticated.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>REQUIRED.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>REQUIRED.</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
Loading…
Reference in New Issue