New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add register-and-verify extension #276

Open
wants to merge 16 commits into
from

Conversation

Projects
None yet
9 participants
@DanielOaks
Member

DanielOaks commented Nov 7, 2016

The REG command framework provides a unified, standardized interface for account creation and validation to the network's authentication layer. This allows for a network to provide a common interface regardless of what authentication layer they have chosen for their network to operate.

This allows clients to develop tailored interfaces for registering accounts.

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

Show outdated Hide outdated extensions/reg-core-3.3.md
* `certfp`: the client certificate fingerprint as determined by the server if available.
The client MAY provide an empty credential (`*`) in this case. The server SHOULD calculate
the credential using the client certificate fingerprint, if available. If no client certificate
is presented, the server SHOULD NOT advertise the availability of this credential type.

This comment has been minimized.

@ProgVal

ProgVal Nov 15, 2016

Contributor

What hash algorithm should be used to give a fingerprint other than *? And what format?

@ProgVal

ProgVal Nov 15, 2016

Contributor

What hash algorithm should be used to give a fingerprint other than *? And what format?

This comment has been minimized.

@DanielOaks

DanielOaks Nov 17, 2016

Member

Yeah the language here is a bit iffy, thanks for pointing it out. I'll clean this up a bit.

@DanielOaks

DanielOaks Nov 17, 2016

Member

Yeah the language here is a bit iffy, thanks for pointing it out. I'll clean this up a bit.

Show outdated Hide outdated extensions/reg-core-3.3.md
The `REG VERIFY` command signals the intent of a client to submit a verification token for their
account to the authentication layer. The verification token MUST be sent to a valid callback
resource as specified by the client in the `REG CREATE` command.

This comment has been minimized.

@ProgVal

ProgVal Nov 15, 2016

Contributor

If a verification token is required by the server, it MUST be sent by the IRC network to a valid callback resource [...]”

@ProgVal

ProgVal Nov 15, 2016

Contributor

If a verification token is required by the server, it MUST be sent by the IRC network to a valid callback resource [...]”

Show outdated Hide outdated extensions/reg-core-3.3.md
account that has been successfully verified.
Upon error, the IRC server MUST send an error code that is relevant. We suggest these
numerics:

This comment has been minimized.

@ProgVal

ProgVal Nov 15, 2016

Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

@ProgVal

ProgVal Nov 15, 2016

Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

Show outdated Hide outdated extensions/reg-core-3.3.md
:irc.example.com 005 kaniini REGCREDTYPES=passphrase,certfp :are supported by this server
The first credential type SHOULD be the implementation-defined default if default credential types
are supported.

This comment has been minimized.

@ProgVal

ProgVal Nov 15, 2016

Contributor

I did not understand this line at first.
Do you mean this? “The order credential type SHOULD be the implementation-defined default if both credential types are supported.

@ProgVal

ProgVal Nov 15, 2016

Contributor

I did not understand this line at first.
Do you mean this? “The order credential type SHOULD be the implementation-defined default if both credential types are supported.

Show outdated Hide outdated extensions/reg-core-3.3.md
| --- | ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 927 | `RPL_REG_VERIFICATION_REQUIRED` | `:<server> 927 <user_nickname> <accountname> <callback_namespace:><callback> :A verification token was sent` |
Upon error, the IRC server MUST send an error code that is relevant. We suggest these numerics:

This comment has been minimized.

@ProgVal

ProgVal Nov 15, 2016

Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

@ProgVal

ProgVal Nov 15, 2016

Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

reg-core: Cleanup unclear language
Thanks to @ProgVal for the suggestions.
@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Nov 17, 2016

Member

@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

Member

DanielOaks commented Nov 17, 2016

@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

Add REGNICK token, allow * for accountname = nick.
These changes allow REG to be better used on networks that explicitly link accounts to nicknames.
@ProgVal

This comment has been minimized.

Show comment
Hide comment
@ProgVal

ProgVal Nov 18, 2016

Contributor

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.

Contributor

ProgVal commented Nov 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Nov 18, 2016

Member

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.

Member

DanielOaks commented Nov 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@grawity

grawity Nov 18, 2016

Contributor

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.

Contributor

grawity commented Nov 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Nov 18, 2016

Member

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).

Member

DanielOaks commented Nov 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ProgVal

ProgVal Nov 18, 2016

Contributor

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.

Contributor

ProgVal commented Nov 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Nov 19, 2016

Member

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).

Member

DanielOaks commented Nov 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ProgVal

ProgVal Nov 19, 2016

Contributor

Ok

Contributor

ProgVal commented Nov 19, 2016

Ok

Show outdated Hide outdated extensions/reg-core-3.3.md
types may or may not allow spaces inside `credential`.
The `callback` field designates an opaque value which indicates where a verification code, if any,
will be sent. The callback field is implementation-specific, with namespaces being listed using the

This comment has been minimized.

@M2Ys4U

M2Ys4U Nov 19, 2016

Contributor

If we're using IANA-registered scheme names for the callback namespace, does it make sense that the callback field is implementation-specific? Why not just use a proper URI here?

@M2Ys4U

M2Ys4U Nov 19, 2016

Contributor

If we're using IANA-registered scheme names for the callback namespace, does it make sense that the callback field is implementation-specific? Why not just use a proper URI here?

This comment has been minimized.

@DanielOaks

DanielOaks Jan 7, 2017

Member

Makes sense, thanks for the suggestion. I'll look at this.

@DanielOaks

DanielOaks Jan 7, 2017

Member

Makes sense, thanks for the suggestion. I'll look at this.

@jwheare jwheare added the accounts label Jan 7, 2017

@jwheare jwheare modified the milestone: Roadmap Jan 7, 2017

Show outdated Hide outdated extensions/reg-core-3.3.md
A `REG VERIFY` command consists of the following format:
REG VERIFY <accountname> <auth_code>

This comment has been minimized.

@Zarthus

Zarthus Jan 7, 2017

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

Zarthus Jan 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Zarthus

Zarthus Jan 7, 2017

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

Zarthus commented Jan 7, 2017

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

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Jan 7, 2017

Member

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

Member

DanielOaks commented Jan 7, 2017

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

@prawnsalad

This comment has been minimized.

Show comment
Hide comment
@prawnsalad

prawnsalad Jan 7, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Jan 7, 2017

Member

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.

Member

DanielOaks commented Jan 7, 2017

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.

Show outdated Hide outdated extensions/reg-core-3.3.md
| --- | ------------------- | ------------------------------------------------------------------------------ |
| 923 | `RPL_VERIFYSUCCESS` | `:<server> 923 <user_nickname> <accountname> :Account verification successful` |
The IRC server SHOULD also send an `RPL_LOGGEDIN` (900) numeric and consider the client to be logged in to the

This comment has been minimized.

@Zarthus

Zarthus Jan 7, 2017

Sounds better defined as a MUST.

@Zarthus

Zarthus Jan 7, 2017

Sounds better defined as a MUST.

@prawnsalad

This comment has been minimized.

Show comment
Hide comment
@prawnsalad

prawnsalad Jan 7, 2017

@DanielOaks In that case then the examples need updating to reflect that. They currently show verification mailto: being sent and then a 920 being received before 927.

@DanielOaks In that case then the examples need updating to reflect that. They currently show verification mailto: being sent and then a 920 being received before 927.

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Jan 7, 2017

Member

@prawnsalad oh, weird. yeah I'll def go over that and make sure it's made clearer and all, thanks for pointing that out!

Member

DanielOaks commented Jan 7, 2017

@prawnsalad oh, weird. yeah I'll def go over that and make sure it's made clearer and all, thanks for pointing that out!

@MuffinMedic

This comment has been minimized.

Show comment
Hide comment
@MuffinMedic

MuffinMedic Feb 20, 2017

Contributor

Rather than have a specification solely for registration purposes, a general ACCOUNT command spec would be more extensible and allow for easier implementation of adding on new features later. Account management includes actions other than registration and verification, such as updating details, deleting, etc...

With this current spec, each of these additional features would need to be written as its own spec from the ground up, which will fragment similar features across multiple. Using an ACCOUNT command and implementing REG as one of potentially many extensions (subcommands) enables things such as DELETE and UPDATE to be wrapped into a single spec as extensions, keeps related features together, and makes improvements easier down the line.

Having a single ACCOUNT spec also enables standardization of certain elements across various account features, such as the same recommended security checks for all account features and consistency with the command format. At the same time, this allows for individual extensions to add the changes they need (new sub-command) while maintaining this consistency.

The ACCOUNT spec/command could follow a similar format to below, with each subcommand its own extension.

ACCOUNT EXTENSION_SUBCOMMAND parameters

ACCOUNT CREATE accountname callback credentials
ACCOUNT VERIFY [accountname] auth_code
ACCOUNT UPDATE [accountname] email new_email
ACCOUNT DELETE accountname credentials
Contributor

MuffinMedic commented Feb 20, 2017

Rather than have a specification solely for registration purposes, a general ACCOUNT command spec would be more extensible and allow for easier implementation of adding on new features later. Account management includes actions other than registration and verification, such as updating details, deleting, etc...

With this current spec, each of these additional features would need to be written as its own spec from the ground up, which will fragment similar features across multiple. Using an ACCOUNT command and implementing REG as one of potentially many extensions (subcommands) enables things such as DELETE and UPDATE to be wrapped into a single spec as extensions, keeps related features together, and makes improvements easier down the line.

Having a single ACCOUNT spec also enables standardization of certain elements across various account features, such as the same recommended security checks for all account features and consistency with the command format. At the same time, this allows for individual extensions to add the changes they need (new sub-command) while maintaining this consistency.

The ACCOUNT spec/command could follow a similar format to below, with each subcommand its own extension.

ACCOUNT EXTENSION_SUBCOMMAND parameters

ACCOUNT CREATE accountname callback credentials
ACCOUNT VERIFY [accountname] auth_code
ACCOUNT UPDATE [accountname] email new_email
ACCOUNT DELETE accountname credentials
@Zarthus

This comment has been minimized.

Show comment
Hide comment
@Zarthus

Zarthus Feb 21, 2017

I personally like how it is extensible, it allows networks to implement some components, make their own, and omit some of the others.

Zarthus commented Feb 21, 2017

I personally like how it is extensible, it allows networks to implement some components, make their own, and omit some of the others.

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Feb 21, 2017

Member

Sure, makes sense. I'll push an update that puts these sort of changes into action.

Note from dx: <dx> is there no conflict with the account command of account-notify?

Member

DanielOaks commented Feb 21, 2017

Sure, makes sense. I'll push an update that puts these sort of changes into action.

Note from dx: <dx> is there no conflict with the account command of account-notify?

DanielOaks added some commits Mar 7, 2017

acc-core: Rename REG to ACC, REG CREATE to ACC REGISTER
I'm doing this to make it more clear that this command specifically affects accounts, and allow for better and easier extension of it later.
@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Mar 7, 2017

Member

Should address most of the concerns here.

Named it ACC rather than ACCOUNT to avoid confusion with the ACCOUNT verb added in account-notify and our other account-info-tracking specs. Let's not bikeshed this for ages, ACC works fine and avoids confusion while allowing for nice extension of the command later (particularly if different commands want to respond in turn with the same verb, or other fun stuff as discussed for alternates to error numerics in the future).

@M2Ys4U How's that language regarding the IANA URI Schemes registry? We'll leave it as 'SHOULD' as it also allows * as a special char and to leave possibilities open.

@prawnsalad Made it so that after ACC REGISTER the server replies with EITHER RPL_REG_SUCCESS or RPL_REG_VERIFICATION_REQUIRED, and not both.

Member

DanielOaks commented Mar 7, 2017

Should address most of the concerns here.

Named it ACC rather than ACCOUNT to avoid confusion with the ACCOUNT verb added in account-notify and our other account-info-tracking specs. Let's not bikeshed this for ages, ACC works fine and avoids confusion while allowing for nice extension of the command later (particularly if different commands want to respond in turn with the same verb, or other fun stuff as discussed for alternates to error numerics in the future).

@M2Ys4U How's that language regarding the IANA URI Schemes registry? We'll leave it as 'SHOULD' as it also allows * as a special char and to leave possibilities open.

@prawnsalad Made it so that after ACC REGISTER the server replies with EITHER RPL_REG_SUCCESS or RPL_REG_VERIFICATION_REQUIRED, and not both.

@MuffinMedic

Change spec framework from registration to management and suggestion to move sub-commands to their own "sub-extensions" (extensions/acc/command)

Show outdated Hide outdated extensions/acc-core.md
email: "daniel@danieloaks.net"
---
The `REG` command framework provides a unified, standardized interface for account creation and
The `ACC` command framework provides a unified, standardized interface for account creation and

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/creation/management/

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/creation/management/

Show outdated Hide outdated extensions/acc-core.md
@@ -25,20 +25,20 @@ authority layer of the network. Further, we believe it is helpful to client aut
they may provide guided account creation and validation for their users, regardless of network

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/creation/management/

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/creation/management/

Show outdated Hide outdated extensions/acc-core.md
REG VERIFY <accountname> <auth_code>
ACC VERIFY <accountname> <auth_code>

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Server should allow overrides - i.e. oper verification of accounts without token.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Server should allow overrides - i.e. oper verification of accounts without token.

Show outdated Hide outdated extensions/acc-core.md
S: 923 kaniini rabbit :Account verification successful
S: 903 kaniini :Authentication successful
### Registering the account "rabbit" with an unsupported verification method:
C: REG CREATE rabbit 1vBjNBdhjWFFbbbbVBHJEWBHJWcfbbvjkhbea passphrase :testpassphrase123
C: ACC REGISTER rabbit 1vBjNBdhjWFFbbbbVBHJEWBHJWcfbbvjkhbea passphrase :testpassphrase123
S: 929 kaniini rabbit 1vBjNBdhjWFFbbbbVBHJEWBHJWcfbbvjkhbea :Callback token is not valid
### Registering the account "rabbit", but providing an invalid verification token:

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Add token for oper overrides (account verified and user notified account was verified for them).

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Add token for oper overrides (account verified and user notified account was verified for them).

Show outdated Hide outdated extensions/acc-core.md
| 440 | `ERR_REG_UNAVAILABLE` | `:<server> 440 <user_nickname> <subcommand> :Authentication services are currently unavailable` |
The server MAY send additional informative text upon registration success or failure using `RPL_TEXT` or `NOTICE`.
## The `REG VERIFY` sub-command
## The `ACC VERIFY` sub-command

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Each subcommand should be it's own extension rather than in the framework spec (extensions/acc/verify).

This allows for a more modular system in which networks can choose which features to support.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Each subcommand should be it's own extension rather than in the framework spec (extensions/acc/verify).

This allows for a more modular system in which networks can choose which features to support.

Show outdated Hide outdated extensions/acc-core.md
below:
## The `REG CREATE` sub-command
## The `ACC REGISTER` sub-command

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Each subcommand should be it's own extension rather than in the framework spec (extensions/acc/register).

This allows for a more modular system in which networks can choose which features to support.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

Each subcommand should be it's own extension rather than in the framework spec (extensions/acc/register).

This allows for a more modular system in which networks can choose which features to support.

Show outdated Hide outdated extensions/acc-core.md
The `REG` command is the main command used by the account registration subsystem. It provides
several subcommands listed in the `REGCOMMANDS` ISUPPORT type. The core sub-commands are listed
The `ACC` command is the main command used by the account registration subsystem. It provides

This comment has been minimized.

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/registration/management/

@MuffinMedic

MuffinMedic Mar 7, 2017

Contributor

s/registration/management/

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Mar 7, 2017

Member

Makes sense, thanks. I'll rewrite a bunch of stuff around how we're structuring it now and throw in an update

Member

DanielOaks commented Mar 7, 2017

Makes sense, thanks. I'll rewrite a bunch of stuff around how we're structuring it now and throw in an update

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Apr 3, 2017

Member

ACC_REQUIRED numeric added to facilitate future use where networks required clients to register an account before connecting. This will come further into play with this particular spec later if/when pre-reg RPL_ISUPPORT makes its way onto the stage.

I should note that this is already useful for those networks that allow/require account registration on a website and require you to use that account to login, for instance. And networks that restrict connections made through proxies/Tor to only clients that have SASL setup.

Member

DanielOaks commented Apr 3, 2017

ACC_REQUIRED numeric added to facilitate future use where networks required clients to register an account before connecting. This will come further into play with this particular spec later if/when pre-reg RPL_ISUPPORT makes its way onto the stage.

I should note that this is already useful for those networks that allow/require account registration on a website and require you to use that account to login, for instance. And networks that restrict connections made through proxies/Tor to only clients that have SASL setup.

@ProgVal

This comment has been minimized.

Show comment
Hide comment
@ProgVal

ProgVal Aug 7, 2018

Contributor

What is the status of implementations?

Contributor

ProgVal commented Aug 7, 2018

What is the status of implementations?

@DanielOaks

This comment has been minimized.

Show comment
Hide comment
@DanielOaks

DanielOaks Aug 8, 2018

Member

Oragono has an up-and-running implementation (including verification). That's about it right now.

Member

DanielOaks commented Aug 8, 2018

Oragono has an up-and-running implementation (including verification). That's about it right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment