Server notices and similar alerts
sent by servers are typically sent by a general purpose user such as @support:example.org. These
messages can look like a phishing attempt
when they lack any "official" markings.
This proposal introduces a simple server-local verification mechanism to identify "verified" accounts. This proposal does not introduce a mechanism to request/assign verification, nor manage that verification - this is left as an implementation detail under this proposal, and may be improved by a future MSC.
The user's global profile has a new
optional m.verified property added, as shown by the below endpoints.
m.verified takes on a slightly weird shape to allow for future expansion, such as the potential
for a signed object, attestation, etc. The m.verified object can only contain a single boolean
currently: verified. When m.verified is supplied, verified can only be true (otherwise the
user is considered "unverified" or "default").
GET /_matrix/client/v3/profile/{userId}
response:
{
"displayname": "Support",
"avatar_url": "mxc://example.org/abc123",
"m.verified": { // new!
"verified": true
}
}If the user is not verified, m.verified will not be present.
New Endpoint - GET /_matrix/client/v3/profile/{userId}/m.verified
No request body.
Response:
{
"m.verified": {
"verified": true
}
}The endpoint behaves similar to GET /_matrix/client/v3/profile/{userId}/displayname:
if the user doesn't exist or is not verified locally on the server, the endpoint returns 404 M_NOT_FOUND.
Note that this new endpoint does not go over federation to determine verified status - for this
proposal, verification is very intentionally a server-local state.
Unlike GET /displayname, there is deliberately no PUT /m.verified partner endpoint.
Verified users SHOULD have a badge next to their name when they send a message or invite within the client's UI, regardless of which room they're in. Clients SHOULD use a custom graphic to denote this verified badge rather than an emoji to prevent phishing attempts from other users.
Clients SHOULD also show a warning or "unverified" badge when a sender appears to be trying to
indicate that they're verified when they're not. For example, Alice ☑️ or Alice [VERIFIED].
It is left as an implementation detail for how to assign/request verification status. A server might,
for example, put a policy in place where only specific individuals receive verification status with
no opportunity to apply. Another server might require requests to be sent to @support:example.org.
A given user's name can appear in a number of places within a client, potentially leading to thousands
of calls for verification status. To help reduce this request spam, calls to GET /_matrix/client/v3/profile/{userId}/m.verified
MUST be cached by clients, either by respecting the Cache-Control
header, or for a minimum of 24 hours. Similarly, m.verified on the general /profile/{userId}
endpoint must be cached for at least 24 hours.
Verification status is not expected to change often, so longer cache values are preferred.
This proposal doesn't work over federation. This is a feature, not a bug. Communicating verification over federation would ideally mean having a method for end clients to confirm the verification without the use of the attached homeserver. Such a problem is challenging to solve quickly.
Significant alternatives are implied throughout. Namely, a proper verification system could be introduced instead, though such a system requires significant engineering effort.
Clients MUST be cautious and warn users of possible phishing attempts relating to verification, as discussed earlier in this MSC.
While this MSC is not considered stable, the following transformations apply:
GET /_matrix/client/v3/profile/{userId}/m.verifiedbecomesGET /_matrix/client/unstable/org.matrix.msc4145/profile/{userId}/org.matrix.msc4145.verifiedm.verifiedbecomesorg.matrix.msc4145.verified
This MSC has no direct dependencies itself.