-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC4108: Mechanism to allow OIDC sign in and E2EE set up via QR code #4108
base: main
Are you sure you want to change the base?
Conversation
finally, it is no longer just an idea presented at FOSDEM 🥳 |
5cd815f
to
177a2db
Compare
…org/matrix-spec-proposals into element-hq/oidc-qr-login
- An indicator (the **intent**) to say if this is a new device which wishes to "initiate" a login, or an existing device | ||
that wishes to "reciprocate" a login |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find these terms ("initiate" and "reciprocate") mildly confusing and always have to pause a second to understand which is which. A better pair might be "petition" and "grant"?
Though if these were chosen to align with some prior art elsewhere, it's not that horrible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the terms are not ideal. I think I chose them as they are used elsewhere in the Client-Server API specification. I'm not sure "petition" and "grant" are better though!
Another way we could describe it is by defining the disposition of the device.
So, the "initiator" could become the "un-authenticated device". And the "reciprocator" could become the "authenticated device"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a device, the unauthenticated one, "wishes" to login and the other, authenticated, one "grants" it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a device, the unauthenticated one, "wishes" to login and the other, authenticated, one "grants" it.
This "grants" terminology clashes with OIDC.
In OIDC the OIDC Provider "grants" access after the user has "consented".
Specifically, the device doesn't have the authority to grant access. Only the OIDC Provider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about `which wishes to login, or an existing device that wishes to open for a login" then?
@@ -220,7 +219,10 @@ The server should allow a minimum payload size of 10KB and enforce a maximum pay | |||
|
|||
###### Maximum duration of a rendezvous | |||
|
|||
The rendezvous session only needs to persist for the duration of the handshake. So a timeout such as 30 seconds is adequate. | |||
The rendezvous session needs to persist for the duration of the login. So a timeout such as 60 seconds should be adequate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 60 seconds is very tight if you have a slow connection, not because of bandwidth but because of latency in establishing the various connections. I'd go for 180 seconds, which I have to admit is just a guesstimate.
No significant changes since 1.106.0rc1. - Send an email if the address is already bound to an user account. ([\#16819](element-hq/synapse#16819)) - Implement the rendezvous mechanism described by [MSC4108](matrix-org/matrix-spec-proposals#4108). ([\#17056](element-hq/synapse#17056)) - Support delegating the rendezvous mechanism described [MSC4108](matrix-org/matrix-spec-proposals#4108) to an external implementation. ([\#17086](element-hq/synapse#17086)) - Add validation to ensure that the `limit` parameter on `/publicRooms` is non-negative. ([\#16920](element-hq/synapse#16920)) - Return `400 M_NOT_JSON` upon receiving invalid JSON in query parameters across various client and admin endpoints, rather than an internal server error. ([\#16923](element-hq/synapse#16923)) - Make the CSAPI endpoint `/keys/device_signing/upload` idempotent. ([\#16943](element-hq/synapse#16943)) - Redact membership events if the user requested erasure upon deactivating. ([\#17076](element-hq/synapse#17076)) - Add a prompt in the contributing guide to manually configure icu4c. ([\#17069](element-hq/synapse#17069)) - Clarify what part of message retention is still experimental. ([\#17099](element-hq/synapse#17099)) - Use new receipts column to optimise receipt and push action SQL queries. Contributed by Nick @ Beeper (@Fizzadar). ([\#17032](element-hq/synapse#17032), [\#17096](element-hq/synapse#17096)) - Fix mypy with latest Twisted release. ([\#17036](element-hq/synapse#17036)) - Bump minimum supported Rust version to 1.66.0. ([\#17079](element-hq/synapse#17079)) - Add helpers to transform Twisted requests to Rust http Requests/Responses. ([\#17081](element-hq/synapse#17081)) - Fix type annotation for `visited_chains` after `mypy` upgrade. ([\#17125](element-hq/synapse#17125)) * Bump anyhow from 1.0.81 to 1.0.82. ([\#17095](element-hq/synapse#17095)) * Bump peaceiris/actions-gh-pages from 3.9.3 to 4.0.0. ([\#17087](element-hq/synapse#17087)) * Bump peaceiris/actions-mdbook from 1.2.0 to 2.0.0. ([\#17089](element-hq/synapse#17089)) * Bump pyasn1-modules from 0.3.0 to 0.4.0. ([\#17093](element-hq/synapse#17093)) * Bump pygithub from 2.2.0 to 2.3.0. ([\#17092](element-hq/synapse#17092)) * Bump ruff from 0.3.5 to 0.3.7. ([\#17094](element-hq/synapse#17094)) * Bump sigstore/cosign-installer from 3.4.0 to 3.5.0. ([\#17088](element-hq/synapse#17088)) * Bump twine from 4.0.2 to 5.0.0. ([\#17091](element-hq/synapse#17091)) * Bump types-pillow from 10.2.0.20240406 to 10.2.0.20240415. ([\#17090](element-hq/synapse#17090))
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
This commits adds a Elliptic Curve Encryption Scheme, this scheme can be used in ephemeral situations where a full 3DH-based Olm session might be overkill or too hard to set up. The canonical example where this can be used is the QR code login feature in Matrix[1]. Co-authored-by: Denis Kasak <dkasak@termina.org.uk> Co-authored-by: Hugh Nimmo-Smith <hughns@users.noreply.github.com> [1]: matrix-org/matrix-spec-proposals#4108
Co-authored-by: Damir Jelić <poljar@termina.org.uk>
This implements one part of MSC4108[1], it implements the case where the new device scans the QR code. [1]: matrix-org/matrix-spec-proposals#4108
This implements one part of MSC4108[1], it implements the case where the new device scans the QR code. [1]: matrix-org/matrix-spec-proposals#4108
Co-authored-by: Damir Jelić <poljar@termina.org.uk>
# Synapse 1.109.0 (2024-06-18) - Add the ability to auto-accept invites on the behalf of users. See the [`auto_accept_invites`](https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html#auto-accept-invites) config option for details. ([\#17147](element-hq/synapse#17147)) - Add experimental [MSC3575](matrix-org/matrix-spec-proposals#3575) Sliding Sync `/sync/e2ee` endpoint for to-device messages and device encryption info. ([\#17167](element-hq/synapse#17167)) - Support [MSC3916](matrix-org/matrix-spec-proposals#3916) by adding unstable media endpoints to `/_matrix/client`. ([\#17213](element-hq/synapse#17213)) - Add logging to tasks managed by the task scheduler, showing CPU and database usage. ([\#17219](element-hq/synapse#17219)) # Synapse 1.108.0 (2024-05-28) - Add a feature that allows clients to query the configured federation whitelist. Disabled by default. ([\#16848](element-hq/synapse#16848), [\#17199](element-hq/synapse#17199)) - Add the ability to allow numeric user IDs with a specific prefix when in the CAS flow. Contributed by Aurélien Grimpard. ([\#17098](element-hq/synapse#17098)) Synapse 1.107.0 (2024-05-14) - Add preliminary support for [MSC3823: Account Suspension](matrix-org/matrix-spec-proposals#3823). ([\#17051](element-hq/synapse#17051)) - Declare support for [Matrix v1.10](https://matrix.org/blog/2024/03/22/matrix-v1.10-release/). Contributed by @clokep. ([\#17082](element-hq/synapse#17082)) - Add support for [MSC4115: membership metadata on events](matrix-org/matrix-spec-proposals#4115). ([\#17104](element-hq/synapse#17104), [\#17137](element-hq/synapse#17137)) # Synapse 1.106.0 (2024-04-30) - Send an email if the address is already bound to an user account. ([\#16819](element-hq/synapse#16819)) - Implement the rendezvous mechanism described by [MSC4108](matrix-org/matrix-spec-proposals#4108). ([\#17056](element-hq/synapse#17056)) - Support delegating the rendezvous mechanism described [MSC4108](matrix-org/matrix-spec-proposals#4108) to an external implementation. ([\#17086](element-hq/synapse#17086))
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
Rendered
Dependencies:
Implementations:
Video demo: