From a81491ca2b7143402ef15870d49ac3254615203c Mon Sep 17 00:00:00 2001 From: Hugh Nimmo-Smith Date: Wed, 10 Apr 2024 16:23:26 +0100 Subject: [PATCH] Add error codes --- proposals/4108-oidc-qr-login.md | 28 ++++++++++++---------------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/proposals/4108-oidc-qr-login.md b/proposals/4108-oidc-qr-login.md index ecb196dd7..962ddcf39 100644 --- a/proposals/4108-oidc-qr-login.md +++ b/proposals/4108-oidc-qr-login.md @@ -848,7 +848,7 @@ sequenceDiagram note over E: Existing device checks that requested protocol is supported alt if requested protocol is not valid - E->>N: SecureSend({"type":"m.login.failure", "reason":"unsupported",
"homeserver": "https://matrix-client.matrix.org}) + E->>N: SecureSend({"type":"m.login.failure", "reason":"unsupported_protocol",
"homeserver": "https://matrix-client.matrix.org}) end end ``` @@ -916,7 +916,7 @@ sequenceDiagram note over E: Existing device checks that requested protocol is supported alt if requested protocol is not valid - E->>N: SecureSend({"type":"m.login.failure", "reason":"unsupported",
"homeserver": "https://matrix-client.matrix.org}) + E->>N: SecureSend({"type":"m.login.failure", "reason":"unsupported_protocol",
"homeserver": "https://matrix-client.matrix.org}) end end ``` @@ -959,7 +959,7 @@ existing device then asserts that there is no existing device corresponding to t It does so by calling [GET /_matrix/client/v3/devices/](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3devicesdeviceid) and expecting to receive an HTTP 404 response. -If the device already exists then the login request should be rejected with an `m.login.failure`. +If the device already exists then the login request should be rejected with an `m.login.failure` and reason `device_already_exists`. If no existing device was found then the existing device opens the `verification_uri_complete` - falling back to the `verification_uri`, if `verification_uri_complete` isn’t present - in a system browser. @@ -1003,10 +1003,14 @@ sequenceDiagram OP-->>N: 400 Bad Request {"error": "authorization_pending"} else granted OP-->>N: 200 OK {"access_token": "...", "token_type": "Bearer", ...} + N->>E: SecureSend({ "type": "m.login.success" }) + Note over N: Device now has an access_token and can start to talk to the homeserver else denied OP-->>N: 400 Bad Request {"error": "authorization_declined"} + N->>E: SecureSend({"type":"m.login.declined"}) else expired OP-->>N: 400 Bad Request {"error": "expired_token"} + N->>E: SecureSend({"type":"m.login.failure", "reason": "authorization_expired"}) end end and @@ -1019,14 +1023,6 @@ sequenceDiagram end Note over UA: User closes browser end - - alt declined - Note over E: or can the OP tell the existing device the outcome? - N->>E: SecureSend({"type":"m.login.declined"}) - else approved - Note over N: Device now has an access_token and can start to talk to the homeserver - N->>E: SecureSend({ "type": "m.login.success" }) - end end ``` @@ -1048,7 +1044,7 @@ This is achieved as following: 1. **Existing device confirms that the new device has indeed logged in successfully** -On receipt of an m.login.success message the existing device queries the homeserver to check that the is a device online +On receipt of an `m.login.success` message the existing device queries the homeserver to check that the is a device online with the corresponding device_id (from the `m.login.protocol` message). It does so by calling [GET /_matrix/client/v3/devices/](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3devicesdeviceid) @@ -1080,7 +1076,7 @@ The existing device sends a `m.login.secrets` message via the secure channel: 3. **New device cross-signs itself and uploads device keys** -On receipt of the m.login.secrets message the new device can store the secrets locally +On receipt of the `m.login.secrets` message the new device can store the secrets locally The new device can then generate the cross-signing signature for itself. @@ -1139,7 +1135,7 @@ activate HS alt is device not found note over E: We should wait and retry for 10 seconds HS->>E: 404 Not Found - E->>N: { "type": "m.login.failed", "reason": "TODO" } + E->>N: { "type": "m.login.failure", "reason": "device_not_found" } else is device found HS->>E: 200 OK deactivate HS @@ -1253,9 +1249,9 @@ Fields: |Field|Type|| |--- |--- |--- | |`type`|required `string`|`m.login.failure`| -|`reason`|required `string`| One of: `TODO`| +|`reason`|required `string`| One of:
Value Description
authorization_expired The Device Authorization Grant expired
device_already_exists The device ID specified by the new client already exists in the Homeserver provided device list
device_not_foundThe new device is not present in the device list as returned by the Homeserver
unexpected_message_receivedSent by either device to indicate that they received a message of a type that they weren't expecting
unsupported_protocolSent by a device where no suitable protocol is available or the requested protocol requested is not supported
user_cancelledSent by either new or existing device to indicate that the user has cancelled the login
| |`homeserver`|`string`| When the existing device is sending this it can include the Base URL of the homeserver so that the new device can at least save the user the hassle of typing it in| - + Example: ```json