MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code #4108
Conversation
hughns
changed the title
turt2live
added
proposal
|
finally, it is no longer just an idea presented at FOSDEM 🥳 |
hughns
force-pushed
the
element-hq/oidc-qr-login
branch
from
5cd815f to
177a2db
Compare
…org/matrix-spec-proposals into element-hq/oidc-qr-login
Make rendezvous API optional and return 404. Make authentication on creating rendezvous optional and return 403. Add client header filtering for unsafe content. Clean up for readability.
Clarify original thinking behind QR format. Add notes about versioning and unstable prefixes
turt2live
removed
matrix-2.0
turt2live
moved this from Ready for general review
to Proposed for FCP readiness
in Spec Core Team Workflow
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 <[email protected]> Co-authored-by: Hugh Nimmo-Smith <[email protected]> [1]: matrix-org/matrix-spec-proposals#4108
| 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. | ||
|
|
||
| Ideally this is in a trusted/secure environment where the cookie jar and password manager features are available. e.g. | ||
| on iOS this could be a `ASWebAuthenticationSession` | ||
|
|
||
| The existing device then sends an acknowledgement message to let the other device know that the consent process is in progress: |
There was a problem hiding this comment.
When implementing this in matrix-rust-sdk, @poljar raised the question of whether the order of opening the browser on the existing device and sending the m.login.protocol_accepted message to the new device matters. Should we first send the acknowledgment so that the new device can start polling and only then open the browser to let the user consent?
I think it doesn't make a huge difference but wanted to double check it here.
(Full discussion in matrix-org/matrix-rust-sdk#5801 (comment))
There was a problem hiding this comment.
I have some recollection on this topic:
On receipt of the verification URI the existing device might not be able to open it. Perhaps the operating system denies the request, or it turns out that the isn't a system browser available.
As such I think the intention was that m.login.protocol_accepted is only sent after the device knows that it can proceed with showing the URI.
But the MSC doesn't say this, and nor does the seem to be a suitable m.login.failure reason code defined.
If this was defined then I don't think it matters if the new device starts polling before it has received the m.login.protocol_accepted. But, it would need to stop and do something sensible if it received a m.login.failure instead of m.login.protocol_accepted.
The byte immediately following the `MATRIX` prefix is repurposed as a type which gives a more sensible way to namespace in future. This also means that we can call the second byte the "intent" very clearly rather than having to call it "mode" to match the existing cross verification QR spec.
Rendered
Dependencies:
Video demo:
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:
unstable_features.org.matrix.msc4108istruein/versionsresponse from homeserverunstable_features.io.element.msc4108istruein/versionsresponse from homeserverThe high-level to-do list for the latest version:
Proof-of-MSC implementations
2024 version
Implementations for 2024 version:
Latest version