Skip to content

MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code#4108

Open
hughns wants to merge 81 commits into
mainfrom
element-hq/oidc-qr-login
Open

MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code#4108
hughns wants to merge 81 commits into
mainfrom
element-hq/oidc-qr-login

Conversation

@hughns
Copy link
Copy Markdown
Member

@hughns hughns commented Feb 22, 2024 •
edited
Loading

SCT Stuff

MSC Checklist

FCP tickyboxes

Designated reviewers:

Rendered

Dependencies:

Video demos:

New EX scans existing EW
MSC4108 v2025 New EX scans existing EW

Existing EX scans new EW
MSC4108 v2025 Existing EX scans new EW

New EX scans existing EX
MSC4108 v2025 New EX scans existing EX

The authors are employed by Element to write this MSC.

Major revisions

The is an older version of this proposal (referred to as "2024") that has some significant differences from the current proposal.

To help avoid confusion on the status, the following is hopefully helpful:

Version name Status Proposal revision Supported by Encryption scheme Discovery of support Proof-of-MSC implementation status
2025 MSC is feature complete and being reviewed Diff to 2024 version latest No production implementations. Experimental feature in Synapse. HPKE Discovery using GET /_matrix/client/v1/rendezvous Fully implemented (see below)
2024 Feature complete, but will be superseded by a new version 87f8317 Experimental feature in Synapse. Supported by Element Web/Desktop to generate QR. Supported by Element X to scan QR to login. ECIES unstable_features.org.matrix.msc4108 is true in /versions response from homeserver Fully implemented (see below)

Proof-of-MSC implementations

2025 version

Flows implemented

Flow Existing device New device
Existing device generates QR to sign in a new device EW or EX EX
Existing device scans QR to sign in a new device EX EW

2024 version

Implementations for 2024 version:

MSC4108 Element X-Web iOS demo

To-dos

The high-level to-do list for the latest version:

  • Update rendezvous session API to avoid issues with ETags
  • Update rendezvous session API so that stylistically it fits better with C-S API
  • Allow rendezvous session creation to require authentication
  • Replace ECIES with HPKE in secure channel
  • Revisit QR code format
  • Proof-of-MSC implementations for all of above
  • Review thread about sequence of protocol_accepted
  • Provide a discovery mechanism that works once the proposal is stabilised

@hughns hughns changed the title Mechanism to allow OIDC sign in and E2EE set up via QR code MSC4108: Mechanism to allow OIDC sign in and E2EE set up via QR code Feb 22, 2024
@turt2live turt2live added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Feb 22, 2024
@cyrneko
Copy link
Copy Markdown

cyrneko commented Feb 22, 2024

finally, it is no longer just an idea presented at FOSDEM 🥳

@ara4n
Copy link
Copy Markdown
Member

ara4n commented Feb 22, 2024

tbf there was already MSC3906 - which this will presumably replace, by making it play nice with native OIDC (MSC3861) :)

@hughns hughns force-pushed the element-hq/oidc-qr-login branch from 5cd815f to 177a2db Compare April 3, 2024 15:58
dkasak
dkasak reviewed Apr 5, 2024
View reviewed changes
Comment thread proposals/4108-oidc-qr-login.md Outdated
dkasak
dkasak reviewed Apr 5, 2024
View reviewed changes
Comment thread proposals/4108-oidc-qr-login.md Outdated
This was referenced Apr 9, 2024
Closed
Closed
Closed
@turt2live
Copy link
Copy Markdown
Member

turt2live commented Mar 30, 2026

The author believes this is ready for FCP. Next steps are for SCT members to review the MSC and implementation(s), add the checklist, then propose FCP if appropriate.

@github-project-automation github-project-automation Bot moved this to Tracking for review in Spec Core Team Workflow Mar 30, 2026
@turt2live turt2live moved this from Tracking for review to Proposed for FCP readiness in Spec Core Team Workflow Mar 30, 2026
@hughns hughns requested a review from turt2live April 23, 2026 11:00
@turt2live turt2live removed their request for review April 27, 2026 21:57
msk pushed a commit to msk/pkgsrc that referenced this pull request May 11, 2026
chat/matrix-synapse: Update to 1.109.0
5a3187a 
# 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))
jperkin pushed a commit to TritonDataCenter/pkgsrc that referenced this pull request May 14, 2026
chat/matrix-synapse: Update to 1.109.0
9e67078 
# 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))
turt2live
turt2live approved these changes May 20, 2026
View reviewed changes
Copy link
Copy Markdown
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've done a brief requirements review, and this proposal appears to be ready for FCP with a dependency on MSC4388 (other dependencies are already merged)

@turt2live
Copy link
Copy Markdown
Member

turt2live commented May 20, 2026

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

MSC authors: feel free to ask in a thread on your MSC or in the#matrix-spec:matrix.org room for clarification of any of these points.

  • Are appropriate implementation(s) specified in the MSC’s PR description?
  • Are all MSCs that this MSC depends on already accepted?
  • For each new endpoint that is introduced:
    • Have authentication requirements been specified?
    • Have rate-limiting requirements been specified?
    • Have guest access requirements been specified?
    • Are error responses specified?
      • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
        • If a new errcode is introduced, is it clear that it is new?
  • Will the MSC require a new room version, and if so, has that been made clear?
    • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
  • Are backwards-compatibility concerns appropriately addressed?
  • Are the endpoint conventions honoured?
    • Do HTTP endpoints use_underscores_like_this?
    • Will the endpoint return unbounded data? If so, has pagination been considered?
    • If the endpoint utilises pagination, is it consistent with the appendices?
  • An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
  • All outstanding threads are resolved
    • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
  • While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
    • Introduction
    • Proposal text
    • Potential issues
    • Alternatives
    • Dependencies
  • Stable identifiers are used throughout the proposal, except for the unstable prefix section
    • Unstable prefixes consider the awkward accepted-but-not-merged state
    • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
  • Changes have applicable Sign Off from all authors/editors/contributors
  • There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

@turt2live
Copy link
Copy Markdown
Member

turt2live commented May 20, 2026

@mscbot fcp merge

Designated reviewers will be copied from MSC4388 given it's in the same area.

@mscbot
Copy link
Copy Markdown
Collaborator

mscbot commented May 20, 2026 •
edited
Loading

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

Concerns:

  • Dependency on MSC4388 outstanding

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. disposition-merge Process state. labels May 20, 2026
@turt2live turt2live added 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. and removed implementation-needs-checking The MSC has an implementation, but the SCT has not yet checked it. Process state. labels May 20, 2026
@turt2live turt2live moved this from Proposed for FCP readiness to Ready for FCP ticks in Spec Core Team Workflow May 20, 2026
turt2live
turt2live reviewed May 20, 2026
View reviewed changes
Comment thread proposals/4108-oidc-qr-login.md
Copy link
Copy Markdown
Member

@turt2live turt2live May 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mscbot concern Dependency on MSC4388 outstanding

@mscbot mscbot added the unresolved-concerns This proposal has at least one outstanding concern. Process state. label May 20, 2026
richvdh
richvdh approved these changes May 26, 2026
View reviewed changes
Copy link
Copy Markdown
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally this seems like an excellent, well-written proposal. I particularly appreciated the separate "Message reference" section as a way to separate the protocol object definitions from the description of the flow.

Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment on lines +854 to +855
- The backup cannot be immediately enabled since we received the backup version as well, something the `m.secret.send`
mechanism does not offer.
Copy link
Copy Markdown
Member

@richvdh richvdh May 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this trying to say that we need to wait for a GET /room_keys request to the homeserver?

Suggested change
- The backup cannot be immediately enabled since we received the backup version as well, something the `m.secret.send`
mechanism does not offer.
- Key backup upload cannot be enabled until we make a `GET /room_keys` request to the homeserver, in order to receive the receive the key backup version.

TBH I'm not sure that's a bad thing: it gives us a chance to ensure that the decryption key we were sent matches the public key for the backup version.

(Also, if all we want is the backup version, we could fix that in secret-sharing too, so I don't think this is an effective argument against using secret sharing for QR code login)

Possibly I'm missing something?

Comment thread proposals/4108-oidc-qr-login.md Outdated
Comment thread proposals/4108-oidc-qr-login.md Outdated
hughns and others added 10 commits June 5, 2026 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@poljar poljar poljar left review comments

@uhoreg uhoreg uhoreg left review comments

@Johennes Johennes Johennes left review comments

@turt2live turt2live turt2live approved these changes

@dkasak dkasak dkasak left review comments

@erikjohnston erikjohnston erikjohnston left review comments

@richvdh richvdh richvdh approved these changes

+5 more reviewers

@tonkku107 tonkku107 tonkku107 left review comments

@davidegirardi davidegirardi davidegirardi left review comments

@networkException networkException networkException left review comments

@zecakeh zecakeh zecakeh left review comments

@noelportillo noelportillo noelportillo left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. A-Client Server Client-Server API disposition-merge Process state. kind:core MSC which is critical to the protocol's success proposal A matrix spec change proposal. Process state. proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the FCP. Process state. unresolved-concerns This proposal has at least one outstanding concern. Process state.

Projects

Spec Core Team Workflow
Status: Ready for FCP ticks

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.