Account Management Framework (now #435)

[DanielOaks]

The ACC command framework provides a standardized way for clients to create and manage accounts. In particular, the ACC REGISTER and ACC VERIFY subcommands should allow a network to provide a consistent interface to register new accounts, no matter what services software is used on the backend. They also let clients build nice interfaces for account registration. This framework is extensible, letting us provide more commands and interfaces in future.

This is the same spec as in #152 but cleaned up and with some bugs fixed. Asked kaniini if I could submit some fixes a while back and he said I should just throw a new PR in.

edit: I think the last thing missing here is the ability to know whether the net uses your nickname as the account name or not. I'll take a look at that and get something worked out there

[DanielOaks]

@progval I'll look at making sure the error codes are in the given list, but how do those changes look to you? Should clean up the language in those sections a fair bit

[progval]

Why do you want to prevent the client from setting a fingerprint that is not the one of its current certificate?
We will have to allow that at some point if we want to allow users to change certificates or use more than one.

[DanielOaks]

Different networks can use whatever fingerprint methods they want for certs. In addition, allowing clients to register with fingerprints other than one that they explicitly control sounds a bit dodgy in terms of spoofing other users. Say that you know the fingerprint of my cert – you register an account with the fingerprint in the certfp's cred field and now I can't register an account linked to my cert because one already exists for it.

Because of that and the difficulty of conveying which algorithm is being used. Does certificate fingerprinting use standardised algorithms like SHA1/SHA256 always or are there cases where people can do whatever special stuff they want, say using both SHA1 and SHA256 to better protect against dodgy collisions? Is there a 100% solid way that we know to convey exactly which method is being used to generate the fingerprint, or should we instead also define a numeric that dumps what your certfp is on connection, so that clients can then use that later in the REG CREATE command?

Just using the client's current cert makes the most sense to me, though if there are answers for all these then I'm open to investigating it further.

[grawity]

Existing services already allow "claiming" any fingerprint anyway. But I like the restriction because it can reduce accidents – if you're only allowed to use your current cert, then registering implies you can successfully connect with it and won't end up with an unusable account.

[DanielOaks]

Updating your cert would be handled separately, if appropriate could be through another REG command we describe later (similar to updating your email address perhaps).

[progval]

But to update the cert, you have to be able to give a fingerprint at some point. Unless you find a way of connecting with the old and the new cert at the same time (IRC in TLS in TLS?), but that may be hard to implement in some/most clients.

[DanielOaks]

I think restricting registration to the certificate you currently have makes sense, for reasons @grawity put above. For updating the cert on an existing account that could definitely make sense, but I think looking at that is the job of another spec (which may also look at updating passphrase/etc for the account as well).

[progval]

Ok

[Zarthus]

I think this should include the (optional?) password if we're going to immediately log the user in [L111]. Or indicate that this command is only available while already logged in (how do you log in?) (in which case the sentence below "the irc server should also send an rpl_loggedin ..." would no longer be valid)

There are many users who accidentally paste their authentication code in chat.

[Zarthus]

Seems to be missing a way to drop the existing nickname. What if I misspell my email?

[DanielOaks]

That's handled by a separate spec. This is just about registering your account

[prawnsalad]

C: REG CREATE * mailto:dan@example.com passphrase :testpassphrase123
S: 920 dan- dan- :Account registered
S: 927 dan- dan- dan@example.com :A verification code was sent

From the client dev perspective, receiving the 920 when verification is still required can cause issues in the UI.

• User attempts to register, UI shows a loading sign
• Client receives the 920, UI shows "congrats" screen
• Client must wait for an arbitrary length of time incase it receives a 927, UI must now change to "Sorry, you're not actually finished. verify now".

Two possible ways to improve this would be to either send 927 before 920, or to send one or the other but never both. The latter would be cleaner IMO.

[DanielOaks]

920's sent when it's successful, so if they do mailto: then it'd send that after they send the REG VERIFY command, not after REG CREATE. If they REG CREATE with skipping verification, they wouldn't get 927 since it requires no verification code to be sent/etc.

[DanielOaks]

So, this is essentially a complete rewrite of the ACC Command Framework spec with the (lots of) feedback kept in mind. No longer relies on ISUPPORT, no longer defines a ton of error numerics and makes use of the FAIL command instead, etc. I think this is much easier to implement, I rewrote the confusing / arbitrarily complex text, and it should support the use cases a lot better in general now.

Let us know what you think.

[xPaw]

Is there a reason why this is called acc and not just account or something like that?

Even looking at the title The ACC command framework gives me no meaningful information at to what this framework is supposed to do.

[DanielOaks]

The account-notify spec already defines the ACCOUNT verb. I can change the title to something better regardless of the actual command name, though.

[DanielOaks]

Bit of a better name, if we wanna brandy alternative suggestions about we can though.

[DanielOaks]

Oragono now implements the updated spec as of the latest git

[DanielOaks]

Mention from the channel on something this could use: "it has no provision afaict for separated verification measures (think "go to this URL and solve a captcha" or "generate this proof of work")"

[DanielOaks]

This tries to do a lot and I think misses the mark in some ways and would probably be better getting rewritten. Especially this long with no real implementations sorta shows that it's probably better to get a more well-defined look at what specifically we should solve in a single spec (e.g. lump registration as well as authentication changing, maybe ^ and whatever other registration/cred-specific things come up), rather than trying to add on later with patch specs like this one's tried to.

I dunno, I'll submit something to -ideas along the lines of a problem statement so we can better nail down what we want out of this and see if there's any actual interest from the not-client side.