3pid invites: remove mentions of display_name

This commit is contained in:
Daniel Wagner-Hall 2015-11-09 17:30:18 +00:00
parent 68bec3a61a
commit 24c2036a35
2 changed files with 6 additions and 13 deletions

View file

@ -84,8 +84,7 @@ paths:
{
"id_server": "matrix.org",
"medium": "email",
"address": "cheeky@monkey.com",
"display_name": "A very cheeky monkey"
"address": "cheeky@monkey.com"
}
properties:
id_server:
@ -98,10 +97,7 @@ paths:
address:
type: string
description: The invitee's third party identifier.
display_name:
type: string
description: A user-friendly string describing who has been invited. It should not contain the address of the invitee, to avoid leaking mappings between third party identities and matrix user IDs.
required: ["id_server", "medium", "address", "display_name"]
required: ["id_server", "medium", "address"]
responses:
200:
description: The user has been invited to join the room.

View file

@ -127,13 +127,10 @@ It is important for user privacy that leaking the mapping between a matrix user
ID and a third party identifier is hard. In particular, being able to look up
all third party identifiers from a matrix user ID (and accordingly, being able
to link each third party identifier) should be avoided wherever possible.
To this end, when implementing this API care should be taken to avoid
adding links between these two identifiers as room events. This mapping can be
unintentionally created by specifying the third party identifier in the
``display_name`` field of the ``m.room.third_party_invite`` event, and then
observing which matrix user ID joins the room using that invite. Clients SHOULD
set ``display_name`` to a value other than the third party identifier, e.g. the
invitee's common name.
To this end, the third party identifier is not put in any event, rather an
opaque display name provided by the identity server is put into the events.
Clients should not remember or display third party identifiers from invites,
other than for the use of the inviter themself.
Homeservers are not required to trust any particular identity server(s). It is
generally a client's responsibility to decide which identity servers it trusts,