MSC1692: Terms of service at registration (#1692)
* Terms of service API proposal * Alter structures to support multiple languages This also introduces an ID for clients to internally reference the policies. * Alter the login process to reflect login's lack of UI auth * Add a note about MSC2140 * Add a flag to the sync response to indicate the sync is withheld * Use the soft logout MSC * Fix headings * Move non-registration bits out * Reference MSC3012 * Adjust wording for new scope * Rewrite to newer modern standards; address feedback from last FCP * Update proposals/1692-terms-at-registration.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Update references --------- Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>old_master
parent
ea24933d10
commit
a19bbeccb1
@ -0,0 +1,92 @@
|
||||
# MSC1692: Terms of service at registration
|
||||
|
||||
At registration, homeservers may wish to require the user to accept a given set of policy documents,
|
||||
such as a terms of service and privacy policy. There may be many different types of documents, all of
|
||||
which are versioned and presented in (potentially) multiple languages.
|
||||
|
||||
This proposal covers requiring users to accept the list of documents during registration. Future
|
||||
improvements could include informing the user *after* registration that a document has changed, which
|
||||
has been spun out to [MSC3012](https://github.com/matrix-org/matrix-spec-proposals/pull/3012).
|
||||
|
||||
## Proposal
|
||||
|
||||
The [User-Interactive Authentication](https://spec.matrix.org/v1.9/client-server-api/#user-interactive-authentication-api)
|
||||
API (UIA) is currently used during registration to create a new account. In future, it is expected
|
||||
that OIDC will be used instead, which can include support for this MSC's principles without needing
|
||||
to change the Matrix specification itself. As a measure until OIDC is here though, this MSC exists
|
||||
to fill the need.
|
||||
|
||||
A new `m.login.terms` authentication type is introduced, allowing servers to include it in registration
|
||||
flows if it desires. Servers which do not require policy acceptance at registration are not required
|
||||
to support this flow.
|
||||
|
||||
The parameters for the new authentication type look like the following:
|
||||
|
||||
```json
|
||||
{
|
||||
"policies": {
|
||||
"terms_of_service": {
|
||||
"version": "1.2",
|
||||
"en": {
|
||||
"name": "Terms of Service",
|
||||
"url": "https://example.org/somewhere/terms-1.2-en.html"
|
||||
},
|
||||
"fr": {
|
||||
"name": "Conditions d'utilisation",
|
||||
"url": "https://example.org/somewhere/terms-1.2-fr.html"
|
||||
}
|
||||
},
|
||||
"privacy_policy": {
|
||||
"version": "1.2",
|
||||
"en": {
|
||||
"name": "Privacy Policy",
|
||||
"url": "https://example.org/somewhere/privacy-1.2-en.html"
|
||||
},
|
||||
"fr": {
|
||||
"name": "Politique de confidentialité",
|
||||
"url": "https://example.org/somewhere/privacy-1.2-fr.html"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Each key under `policies` is a "Policy ID", and defined by the server. They are an opaque identifier
|
||||
(described later in this proposal). Each policy object associated with the policy ID has a required
|
||||
`version` as a convenience to the client, and is another opaque identifier. All other keys are language
|
||||
codes to represent the same document. The client picks the language which best suits the user.
|
||||
|
||||
Language codes *should* be formatted as per [Section 2.2 of RFC 5646](https://datatracker.ietf.org/doc/html/rfc5646#section-2.2),
|
||||
noting that some implementation *may* use an underscore instead of dash. For example, `en_US` instead
|
||||
of `en-US`. This recommendation is to ensure maximum compatibility with existing conventions around
|
||||
language choices in (Matrix) clients.
|
||||
|
||||
`name` and `url` for each policy document are required, and are arbitrary strings with no maximum
|
||||
length. `url` *must* be a valid URI with scheme `https://` or `http://`. Insecure HTTP is discouraged.
|
||||
|
||||
If a client encounters an invalid parameter, registration should stop with an error presented to the
|
||||
user.
|
||||
|
||||
To complete the stage, accepting *all* of the listed documents, the client submits an empty `auth`
|
||||
dict. The client *should* present the user with a checkbox to accept each policy, including a link
|
||||
to the provided `url`, or otherwise rely on [fallback auth](https://spec.matrix.org/v1.9/client-server-api/#fallback).
|
||||
|
||||
The server is expected to track which document versions it presented to the user during registration,
|
||||
if applicable.
|
||||
|
||||
### Opaque identifier
|
||||
|
||||
This definition is inherited from [MSC1597](https://github.com/matrix-org/matrix-spec-proposals/pull/1597).
|
||||
|
||||
> Opaque IDs must be strings consisting entirely of the characters
|
||||
> `[0-9a-zA-Z._~-]`. Their length must not exceed 255 characters and they must
|
||||
> not be empty.
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
Regrettably, this MSC was implemented with *stable* identifiers before an unstable identifiers process
|
||||
was established. Implementation has existed in some capacity since 2018: https://github.com/matrix-org/synapse/pull/4004
|
||||
|
||||
Noting that the modern MSC process forbids such behaviour, new implementations should use the stable
|
||||
`m.login.terms` identifier regardless of MSC status. If the MSC changes in a breaking way, a new
|
||||
identifier *must* be chosen, and *must* include a proper unstable prefix.
|
Loading…
Reference in New Issue