Registration v2 improvements (SPEC-274)

[matrixbot]

v2 registration in its current form has the following problems:

• We don't allow servers to enforce orderings between stages (eg captcha before email)
• We don't uniquely identify stages with distinct params (eg m.login.oauth for Google vs Github)
• We don't allow users to submit multiple stages at once.

I had a nice chat with eternaleye about some of these issues and the main points were:

• We can't enforce captcha before email full stop because the email sending step is done directly by the client to the IS, which has no knowledge of registration flows.
• For stages which have side effects (like sending an email), you really have three options:
  • Eager sending with whitelists. Clients tell the server "I can do these stages". When the server sees that pre-requisite stages are complete AND the client can do the side-effectful stage (e.g. m.login.email.identity) it eagerly sends the email / does the side effect knowing that the client will be able to do the whole thing.
  • Two-step (one step to trigger the side effect, one step to fulfil it). There's no additional RTT costs since side effects inherently involve an extra RTT (e.g. do stuff > side effect > do more stuff)
  • Externally done (but you lose any ability to do ordering).
• Each stage should really have an opaque id to distinguish between the same type with different params (E.g. oauth type hitting Google vs Github) which is sent up to the server.
• The value of having params at the top-level separate from its stage is questionable and in its current form (where this consists of keys with the stage type) don't actually allow you to do the Github vs Google case because you'd clobber params["m.login.oauth"]. Suggestion was to tie params with the actual stage rather than be top-level e.g.

     flows: [
        [
            {
                type: "m.login.oauth2",
                id: "sth",
                params: {
                    url :"http://google.whatever"
                }
            }
        ]
    ]

• We should allow clients to submit multiple stages at once. This could be done using an auth dict like:

    "auth" : {
      "session" : "xxxxx",
      "fulfills" : [
        {type: m.auth.login, id: "abc", ...},
        {type: .... }
      ]
    }

For this to play nicely with ordering, servers would hold back processing later stages even if they have received the data from the client until all previous stages are done (e.g. stages [A,B,C], client submits A,C, only A is processed since they haven't done B yet).

Proposed actions:

• Swap to an id system with coupled params.
• Allow clients to submit multiple stages at once (e.g. with a list of auth dicts).

(Imported from https://matrix.org/jira/browse/SPEC-274)

(Reported by @kegsay)

[matrixbot]

Jira watchers: @kegsay

[matrixbot]

Links exported from Jira:

relates to https://github.com/matrix-org/matrix-doc/issues/430
relates to SYN-396

[matrixbot]

Note that the second and third options for side-effectful stages can be hybridized, so as to retain the separation of concerns where the HS doesn't need to know about how sending emails works, while tying the IS' behavior to the auth flow.

Specifically, the "first step" can return a token that the IS needs to be handed in order to trigger the side effect, and then the side-effect carries the information that needs fed into the "fulfillment" step of the auth stage.

This might be a perfect application of third-party caveats in macaroons - the information in the side effect (email, etc) can be the discharge macaroon.

-- Alex Elsayed

[matrixbot]

https://github.com/matrix-org/matrix-doc/issues/430 possibly related

-- Alex Elsayed

[erlend-sh]

This side note in matrix-org/matrix-spec-proposals#531 :

Note that this is completely different to the role HSes play during reg/login where we ARE the "web app" wanting to authenticate on another 3rd party (FB/G+/etc).

..is exactly what I want to be tracking. #128 seems very relevant to this effort. Anything else I should be looking into?

Simply put, what I want to be tracking is "social logins for a Matrix room/server". As in:

1. User goes to https://riot.im/app/#/room/#matrix-dev:matrix.org for the first time
2. User clicks "Register"
3. User is presented with login options including "GitHub, Facebook, Google+"

This is an essential login flow for non-technical communities.

[kegsay]

It is up to the Homeserver to decide which registration flows it will accept. Presenting buttons like the image above would be ideal for HSes which support OAuth-style registrations/logins, but AFAIK Synapse does not (only LDAP/CAS auth, which is similar but subtly different to OAuth).