Conversation
tantek
left a comment
tantek
left a comment
There was a problem hiding this comment.
LGTM. Made one typo fix suggestion.
martinthomson
left a comment
martinthomson
left a comment
There was a problem hiding this comment.
I am short on time, so a few points of high-level feedback.
Please take the time to look at how other explainers present their case. Treat the template we have as a way to identify points to address, not as something that dictates form.
| <!-- Anna: If the users of MLS are messenger users who'd benefit from MLS, the users of the WebAPI are the | ||
| companies that will develop in top of the standard --> | ||
|
|
||
| The Messaging Layer Security (MLS) standard ([RFC 9420](https://www.rfc-editor.org/rfc/rfc9420.html)) addresses the challenges of scalable, efficient, and standardized end-to-end encryption for group messaging, while ensuring critical security properties such as forward secrecy (FS), post-compromise security (PCS) for groups with more than two participants. |
There was a problem hiding this comment.
This is not a statement of user benefit. This is a preface.
The user benefit is that applications can be built that use keying material that is the result of MLS group key exchange. That has these benefits, but primarily this means that those applications can deliver group messaging with end-to-end properties.
There was a problem hiding this comment.
When I was writing the explainer, my understanding was the following:
Q: What we would like to propose? An API that will cover the core functions and will be used by the main actors.
Then, based on this assumption, who are the users? The people who're going to use the API. Why do they care? secure, written once, all these arguments.
There was a problem hiding this comment.
Pretty much, my emphasis was on the words "API", not "MLS" :)
|
|
||
| The Messaging Layer Security (MLS) standard ([RFC 9420](https://www.rfc-editor.org/rfc/rfc9420.html)) addresses the challenges of scalable, efficient, and standardized end-to-end encryption for group messaging, while ensuring critical security properties such as forward secrecy (FS), post-compromise security (PCS) for groups with more than two participants. | ||
|
|
||
| The standard has already attracted significant attention, with several major vendors expressing interest in implementing it within their products. Providing a single, standardized, and interoperable approach would offer substantial benefits to messaging application developers as well as the organisations willing to deploy MLS-based communication facilities. Ultimately enabling them to deliver native, secure messaging support on the web efficiently and reliably. Once supported across all major browsers, developers would be able to write the integration code once and have it work consistently across platforms, which in turn would significantly reduce development complexity and improve reliability. |
There was a problem hiding this comment.
This is not something you need to say in an explainer.
|
|
||
| ### Methodology for approaching & evaluating solutions | ||
|
|
||
| All vendors require different functionalities to achieve their objectives. Prior to evaluating potential approaches, it is necessary to collect functional requirements from prospective implementers. This process enables a clear distinction between core and optional functionalities. |
|
|
||
| ### Prior/Existing features and/or proposals (if any) that attempt to solve the problem(s) | ||
|
|
||
| Several existing initiatives aim to address the stated user problem. |
There was a problem hiding this comment.
The point of this section is to talk about alternatives. That is, e2ee can be provided by integrating WebCrypto and building a complex system. Or by integrating WASM modules that build MLS or similar cryptosystems, like Signals group key exchange protocol. Or the WebRTC system (or similar) where there are pairwise agreements and a central (trusted) distributor.
4 participants
No description provided.