Account Registration

[DanielOaks]

Account Registration Method Requirements

Goal: Allow registering an account with the IRC network.

Requirements:

• Auth methods:

  • passphrase/PLAIN (username and password)
  • certificate (for SASL EXTERNAL auth)
  • ???

• Verification methods:

  • code transmitted via email
  • code transmitted via sms?
  • go to a url and solve a captcha (possible to just send an email with the url?)
  • generic 'proof of work'? what does this look like and why do this (edk to elaborate on)

• Else:

  • Registering for an account before successfully connecting to the network (i.e. before connection registration has completed)
  • Restricting allowed emails to given domains (e.g. only allowing people with an @ircv3.net email domain to register to the network, and conveying this to the client)
  • Requiring that the 'account name' being registered must be the user's current nickname? however you'd refer to this, whatever irc networks currently do in terms of just registering the current nickname and not anything else

What else does an account registration method need or what should be fleshed-out a bit?

[Herringway]

Will this cover adding/removing extra methods to/from existing accounts? like, for example, adding a certificate and removing it when it expires.

[DanielOaks]

I mean we've tried to get just the registration side done for five years and gotten nowhere. I probably wouldn't add method changes to this effort unless it was pushed/supported by services vendors or related peeps who were into it.

[edk0]

go to a url and solve a captcha (possible to just send an email with the url?)

Given that the idea of this spec is to streamline the process, I'd prefer that the URL is sent to the IRC client directly. The client can then choose to display it as a link or (ideally) in a dialog box.

generic 'proof of work'? what does this look like and why do this (edk to elaborate on)

It looks like Hashcash—this isn't an idea I'm certain will get anywhere, but the idea is to make registration expensive without requiring something personally identifying like an email address or phone number.

[DanielOaks]

Latest work on this is https://github.com/ircv3/ircv3-specifications/pull/435

Regarding the 'other considerations' brought up in the OP:

• Alternate verification methods and/or proof-of-work systems can be worked out later on if services actually implements those, possibly presented with the help of alternate cap values but the human-readable message could also help there.
• "registering for an account before successfully connecting to the network" - Ora does this, and the before-connect key was defined to allow this use case.
• "restricting allowed emails to given domains" - Ora may do this, and if we do we'll likely use a vendor'd cap value key to convey this to clients (though, again, the human-readable messages would make this workable on clients that don't implement special domain/etc checking via that new key.
• "Will this cover adding/removing extra methods to/from existing accounts? like, for example, adding a certificate and removing it when it expires." - no, that can be a new spec not directly related to initial account registration. we should create a new issue for that once the register spec actually gets pushed forward in a material way.

We can always discuss more/alternate proof-of-work systems, but given this issue was mostly about getting account registration at all, with the explorations above based on the flexibility of acc, and now that it looks like we do have a fairly solid, fairly supported way to move forward with this (that matches services implementations more closely) I don't think this issue's necessary anymore.

Go look at the register PR, don't add a bunch of nonsense onto it, and we can implement new things on top of it or adjacent to it later on if we want to. (that changing methods and updating passwords and all that stuff should def be a new spec(s), if someone's motivated to work on that with services then create a new issue for it).