[MLS] Federation and MLS

[Harry Halpin <[e-mail]>]

Glad to see federation being discussed on Thursday as well - here's some thoughts: 

There are basically four issues that need to be solved, and the general philosophy should be one of minimalism. 

1) Identity: How to identify members with different AS/DS? 

There have been large debates over this, ranging from "user@domain" to key-based identifiers to other odd new schemes. To keep it simple, this should be delegated to the Authentication Service to provide long-term identity (or per group) keys, but some minimal set of calls between the AS may need to standardized to retrieve a user key given an identifier. Attempting to standardize the identifier is probably a bad idea, just assume there is a string you can send the AS that returns a key. Thus, the "domain" is by default the "domain" of the AS you call, and all that is needed is a user identifier. This would work well for systems that may not have a clear user@domain architecture. 

2) Discovery: How to determine which capabilities a given MLS-compliant AS/DS supports? 

The typical IETF path is via .well-known [1] or related 'host-meta' [2] and the former seems to be having some usage. From a cryptographic perspective, this is also the 'versioning' issue - how to detect which MLS version is being used, for example, with what ciphersuite (as already we are discussing using non-25519 ciphers). However, the .well-known RFC is tied to the domain name system and so TLS etc, which may not fit all systems. Something even more minimalistic, in a 'federation handshake' to establish connections between AS and DS services and then cryptographically merge their respective sub-trees is a better way to go, although MLS could register a .well-known if needed. 

3) Metadata: 

In general, some sort of metadata will need to be shared, i.e. icons, human readable user-names, group names. I would suggest that as this may be an application message that is simply be considered a non-cryptographic update. Any attempt to proscibe too much on this layer leads to endless bike-shedding and so should be avoided :) However, some minimal optional subset of metadata commonly used for chat could be useful, but rather than whiteboard it, it would be better to have each major MLS vendor that plans to support federation see what their common subset is with everyone else, and then just make a call that delivers just that as an MLS update. 

4) Transport: 

In general, it seems some minimal transport syntax would have to be agreed upon. A simple JSON syntax would match the rest of the Web, without any exotic additions. 

All previous work that is non-minimalistic (and it seems my suggestions could become even more minimized) will lead to failure. For example, OAuth was a success insofar as it did not, unlike OpenID, specify too much. A large summary document I wrote over the last decade of failure of standardization in this space suggests this is the case, with OAuth being the only real victory, everything else from W3C Social Web effort to OpenSocial to a pleathora of 'identity' efforts all more or less failing to reach deployment, see: 
https://hal.inria.fr/hal-01966561/document 

Happy to see MLS focus on the crypto and not repeat the mistakes of previous standards efforts in federation - happy to help on federation topic, although I can't make Prague in person likely. 

yours, 
harry 


[1] https://tools.ietf.org/html/rfc5785 
[2] https://tools.ietf.org/html/rfc6415