Update 3pid invite spec
This takes into account: 1) That finding the existing servers of a room is hard 2) Federationpull/41/head
parent
d2c56fb7a3
commit
af7d2ca9fc
@ -0,0 +1,14 @@
|
|||||||
|
{
|
||||||
|
"age": 242352,
|
||||||
|
"content": {
|
||||||
|
"display_name": "Alice Margatroid",
|
||||||
|
"key_validity_url": "https://magic.forest/verifykey",
|
||||||
|
"public_key": "abc123"
|
||||||
|
},
|
||||||
|
"state_key": "pc98",
|
||||||
|
"origin_server_ts": 1431961217939,
|
||||||
|
"event_id": "$WLGTSEFSEF:localhost",
|
||||||
|
"type": "m.room.third_party_invite",
|
||||||
|
"room_id": "!Cuyf34gef24t:localhost",
|
||||||
|
"sender": "@example:localhost"
|
||||||
|
}
|
@ -0,0 +1,37 @@
|
|||||||
|
{
|
||||||
|
"$schema": "http://json-schema.org/draft-04/schema#",
|
||||||
|
"type": "object",
|
||||||
|
"title": "An invitation to a room issued to a third party identifier, rather than a matrix user ID.",
|
||||||
|
"description": "Acts as an ``m.room.member`` invite event, where there isn't a target user_id to invite. This event contains a token and a public key whose private key must be used to sign the token. Any user who can present that signature may use this invitation to join the target room.",
|
||||||
|
"allOf": [{
|
||||||
|
"$ref": "core#/definitions/state_event"
|
||||||
|
}],
|
||||||
|
"properties": {
|
||||||
|
"content": {
|
||||||
|
"type": "object",
|
||||||
|
"properties": {
|
||||||
|
"display_name": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "A user-readable string which represents the user who has been invited. This should not contain the user's third party ID, as otherwise when the invite is accepted it would leak the association between the matrix ID and the third party ID."
|
||||||
|
},
|
||||||
|
"key_validity_url": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "A URL which can be fetched, with querystring public_key=public_key, to validate whether the key has been revoked. The URL must return a JSON object containing a boolean property named 'valid'."
|
||||||
|
},
|
||||||
|
"public_key": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "A base64-encoded ed25519 key with which token must be signed."
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"required": ["display_name", "key_validity_url", "public_key"]
|
||||||
|
},
|
||||||
|
"state_key": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "The token, of which a signature must be produced in order to join the room."
|
||||||
|
},
|
||||||
|
"type": {
|
||||||
|
"type": "string",
|
||||||
|
"enum": ["m.room.third_party_invite"]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
@ -0,0 +1,39 @@
|
|||||||
|
Third party invites
|
||||||
|
===================
|
||||||
|
|
||||||
|
.. _module:third_party_invites:
|
||||||
|
|
||||||
|
This module adds in support for inviting new members to a room where their
|
||||||
|
Matrix user ID is not known, instead addressing them by a third party identifier
|
||||||
|
such as an email address.
|
||||||
|
|
||||||
|
Events
|
||||||
|
------
|
||||||
|
|
||||||
|
{{m_room_third_party_invite_event}}
|
||||||
|
|
||||||
|
Client behaviour
|
||||||
|
----------------
|
||||||
|
|
||||||
|
A client asks a server to invite a user by their third party identifier.
|
||||||
|
|
||||||
|
See the documentation for /invite for more information.
|
||||||
|
|
||||||
|
Server behaviour
|
||||||
|
----------------
|
||||||
|
|
||||||
|
All homeservers MUST verify that sign(``token``, ``public_key``) = ``signature``.
|
||||||
|
|
||||||
|
If a client of the current homeserver is joining by an
|
||||||
|
``m.room.third_party_invite``, that homesever MUST validate that the public
|
||||||
|
key used for signing is still valid, by checking ``key_validity_url``.
|
||||||
|
|
||||||
|
If a homeserver is joining a room for the first time because of an
|
||||||
|
``m.room.third_party_invite``, the server which is already participating in the
|
||||||
|
room MUST validate that the public key used for signing is still valid, by
|
||||||
|
checking ``key_validity_url``.
|
||||||
|
|
||||||
|
No other homeservers may reject the joining of the room on the basis of
|
||||||
|
``key_validity_url``, this is so that all homeservers have a consistent view of
|
||||||
|
the room.
|
||||||
|
|
Loading…
Reference in New Issue