MSC3231: Token authenticated registration

[govynnus]

Rendered

Signed-off-by: Callum Brown callum@calcuode.com

A couple questions:

• All the other UIAA auth types start m.login, so should I stick with that even though it's registration rather than login? [yes]
• Is the unstable prefix bit right? [yes]

• Synapse implementation
• Nheko implementation using registration token support in mtxclient
• Partial ruma implementation
• Other part of ruma implementation

[anoadragon453]

@cvwright Could I ask that you convert your question into an inline discussion on the PR? It allows for threading an easier management of discussions as the proposal evolves. Otherwise, great question!

[anoadragon453]

This is excellent for a first draft! Short and sweet, though no doubt additional conclusions will be added as discussions progress.

I'm happy that token management is left as an implementation detail. One could argue that various features could be piled on top, such as communicating the amount of uses left on a particular token back to the client. But realistically that would only add unnecessary complication (plus not being easy to do with /register).

As for your initial questions:

All the other UIAA auth types start m.login, so should I stick with that even though it's registration rather than login?

My personal preference is to stick with m.login (which is indeed odd as /login does not use UIAA, but alas...) for consistency, as well as not to confuse people with thinking that the various m.login.* types cannot be used for registration. It may be a nice idea to rename them all in a future, sweeping change though.

Is the unstable prefix bit right?

Yep. org.matrix.msc3231* is fair game, and it looks like a prefix is indeed only required for the registration type. I had one small comment about the wording, but otherwise it looks correct.

[cvwright]

I'm happy that token management is left as an implementation detail. One could argue that various features could be piled on top, such as communicating the amount of uses left on a particular token back to the client. But realistically that would only add unnecessary complication (plus not being easy to do with /register).

It would be great to have another MSC on the topic of token management. Agreed that this does not feel like the right place for it.

Currently Midnight has no HTTP interface for managing or creating tokens. If there were a standard way to do it, I'd be happy to take a stab at implementing that spec.

[govynnus]

@anoadragon453 I agree now that it should stick to m.login. Would m.login.registration-token be OK?

Or you could have m.login.registration_token or m.login.registration.token.

I can't see anywhere in the spec if it says dashes or underscores are preferred.

Edit: I've gone with m.login.registration_token.

[govynnus]

It would be great to have another MSC on the topic of token management. Agreed that this does not feel like the right place for it.

Currently Midnight has no HTTP interface for managing or creating tokens. If there were a standard way to do it, I'd be happy to take a stab at implementing that spec.

As @deepbluev7 mentioned in a Matrix room:

I agree that it would be nice to have a standardized API to generate such tokens, but there are not really any admin endpoints in the spec yet... ._.

That would also entail specifying how tokens can be invalidated (time based, number of uses etc.)

[govynnus]

Also, I've been having a go at a proof-of-concept in Synapse, and found that (similar to captchas) there should be a dummy stage after the token stage if that flow would otherwise only contain the token stage.

That avoids the server seeing a complete flow and doing the registration if clients are actually trying to complete a different flow which might have 3PIDs after the token stage.

(I'm unsure if that's intelligible...)

Should that be mentioned in the MSC?

Edit: I don't think it should be. The spec talks about it for m.login.dummy.

[deepbluev7]

Could we please stick to threads on this MSC for any comments people have, so that it will be easier to see, what is resolved and what is still being discussed? Github sadly gets messy quickly otherwise D:

Just use a random line, if you can't figure out where to put it.

[turt2live]

Spec PR: #3616

[turt2live]

Merged 🎉