Update 3pid spec based on new implementation

event-schemas/examples/v1/m.room.member

@@ -4,21 +4,6 @@
     "membership": "join",
     "avatar_url": "mxc://localhost/SEsfnsuifSDFSSEF#auto",
     "displayname": "Alice Margatroid",
-    "third_party_invite": {
-        "token": "pc98",
-        "public_key": "abc123",
-        "key_validity_url": "https://magic.forest/verifykey",
-        "signed": {
-          "mxid": "@alice:localhost",
-          "token": "pc98",
-          "signatures": {
-            "magic.forest": {
-              "ed25519:0": "poi098"
-            }
-          }
-        },
-        "sender": "@zun:zun.soft"
-    }
   },
   "invite_room_state": [
     {

event-schemas/schema/v1/m.room.member

@@ -1,7 +1,7 @@
 {
     "type": "object",
     "title": "The current membership state of a user in the room.",
-    "description": "Adjusts the membership state for a user in a room. It is preferable to use the membership APIs (``/rooms/<room id>/invite`` etc) when performing membership actions rather than adjusting the state directly as there are a restricted set of valid transformations. For example, user A cannot force user B to join a room, and trying to force this state change directly will fail. \n\nThe ``third_party_invite`` property will be set if the invite was an ``m.room.third_party_invite`` event, and absent if the invite was an ``m.room.member`` event.\n\nThis event also includes an ``invite_room_state`` key **outside the** ``content`` **key**. This contains an array of ``StrippedState`` Events. These events provide information on a few select state events such as the room name.",
+    "description": "Adjusts the membership state for a user in a room. It is preferable to use the membership APIs (``/rooms/<room id>/invite`` etc) when performing membership actions rather than adjusting the state directly as there are a restricted set of valid transformations. For example, user A cannot force user B to join a room, and trying to force this state change directly will fail. \n\nThe ``third_party_invite`` property will be set if this invite is an ``invite`` event and is the successor of an ``m.room.third_party_invite`` event, and absent otherwise.\n\nThis event also includes an ``invite_room_state`` key **outside the** ``content`` **key**. This contains an array of ``StrippedState`` Events. These events provide information on a few select state events such as the room name.",
     "allOf": [{
         "$ref": "core-event-schema/state_event.json"
     }],
@@ -26,18 +26,6 @@
                     "type": "object",
                     "title": "Invite",
                     "properties": {
-                        "token": {
-                            "type": "string",
-                            "description": "A token which must be correctly signed, in order to join the room."
-                        },
-                        "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."
-                        },
                         "signed": {
                             "type": "object",
                             "title": "signed",
@@ -57,13 +45,9 @@
                                 }
                             },
                             "required": ["mxid", "signatures", "token"]
-                        },
-                        "sender": {
-                            "type": "string",
-                            "description": "The matrix user ID of the user who send the invite which is being used."
                         }
                     },
-                    "required": ["token", "key_validity_url", "public_key", "sender", "signed"]
+                    "required": ["signed"]
                 }
             },
             "required": ["membership"]

specification/modules/third_party_invites.rst

@@ -15,13 +15,15 @@ The homeserver asks the identity server whether a Matrix user ID is known for
 that identifier. If it is, an invite is simply issued for that user.
 
 If it is not, the homeserver asks the identity server to record the details of
-the invitation, and to notify the client of this pending invitation if it gets
+the invitation, and to notify the invitee's homeserver of this pending invitation if it gets
 a binding for this identifier in the future. The identity server returns a token
-and public key to the homeserver.
+and public key to the inviting homeserver.
 
-If a client then tries to join the room in the future, it will be allowed to if
-it presents both the token, and a signature of that token from the identity
-server which can be verified with the public key.
+When the invitee's homeserver receives the notification of the binding, it
+should insert an ``m.room.member`` event into the room's graph for that user,
+with ``content.membership`` = ``invite``, as well as a
+``content.third_party_invite`` property whichi contains proof that the invitee
+does indeed own that third party identifier.
 
 Events
 ------
@@ -39,9 +41,10 @@ Server behaviour
 All homeservers MUST verify the signature in the event's
 ``content.third_party_invite.signed`` object.
 
-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``. It does
+When a homeserver inserts an ``m.room.member`` ``invite`` event into the graph
+because of an ``m.room.third_party_invite`` event,
+that homesever MUST validate that the public
+key used for signing is still valid, by checking ``key_validity_url`` from the ``m.room.third_party_invite``. It does
 this by making an HTTP GET request to ``key_validity_url``:
 
 .. TODO: Link to identity server spec when it exists
@@ -91,16 +94,16 @@ For example:
     H1 asks the identity server for a binding to a Matrix user ID, and has none,
     so issues an ``m.room.third_party_invite`` event to the room.
 
-    When the third party user validates their identity, they are told about the
-    invite, and ask their homeserver, H3, to join the room.
+    When the third party user validates their identity, their homeserver, H3,
+    is notified, and attempts to issue an ``m.room.member`` event to participate
+    in the room.
 
-    H3 validates the signature in the event's
-    ``content.third_party_invite.signed`` object.
+    H3 validates the signature given to it by the identity server.
 
     H3 then asks H1 to join it to the room. H1 *must* validate the ``signed``
     property *and* check ``key_validity_url``.
 
-    Having validated these things, H1 writes the join event to the room, and H3
+    Having validated these things, H1 writes the invite event to the room, and H3
     begins participating in the room. H2 *must* accept this event.
 
 The reason that no other homeserver may reject the event based on checking