Skip to content

Commit 45af3f8

Browse files
progvaljwheareedk0slingamnDanielOaks
authored
Add draft account-registration spec (#435)
Co-authored-by: James Wheare <[email protected]> Co-authored-by: Ed Kellett <[email protected]> Co-authored-by: Shivaram Lingamneni <[email protected]> Co-authored-by: Daniel Oaks <[email protected]> Co-authored-by: Sadie Powell <[email protected]> Co-authored-by: James Wheare <[email protected]>
1 parent 5b97d81 commit 45af3f8

File tree

1 file changed

+210
-0
lines changed

1 file changed

+210
-0
lines changed

‎extensions/account-registration.md‎

Lines changed: 210 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,210 @@
1+
---
2+
title: `account-registration` Extension
3+
layout: spec
4+
work-in-progress: true
5+
copyrights:
6+
-
7+
name: "Ed Kellett"
8+
period: "2020"
9+
email: "[email protected]"
10+
-
11+
name: "Val Lorentz"
12+
period: "2021"
13+
email: "[email protected]"
14+
---
15+
16+
## Notes for implementing work-in-progress version
17+
18+
This is a work-in-progress specification.
19+
20+
Software implementing this work-in-progress specification MUST NOT use
21+
the unprefixed `account-registration` capability name.
22+
Instead, implementations SHOULD use the `draft/account-registration`
23+
capability name to be interoperable with other software implementing
24+
a compatible work-in-progress version.
25+
26+
The final version of the specification will use an unprefixed capability name.
27+
28+
## Motivation
29+
30+
A standard method of registering a user account has historically been missing
31+
from IRC. Instead various methods such as sending messages to services bots
32+
(e.g. NickServ) have been employed.
33+
34+
This specification aims to provide a standard baseline for account
35+
registration that allows client developers to build more reliable and
36+
integrated user experiences around account registration.
37+
38+
It does not aim to cover all registration-related use cases that may currently
39+
be in use by server implementations to varying degrees. However, future
40+
extensions to the specification might be proposed given a broad enough
41+
consensus.
42+
43+
### Capability
44+
45+
This specification adds the `draft/account-registration` capability, whose
46+
presence signifies that the server accepts the `REGISTER` command.
47+
48+
The capability MAY be advertised by servers with an OPTIONAL value:
49+
a comma (`,`) (0x2C) separated list of tokens. Each token consists of a key
50+
with an optional value attached. If there is a value attached, the value
51+
is separated from the key by an equals sign (`=`) (0x3D).
52+
That is, `<key>[=<value>][,<key2>[=<value2>][,<keyN>[=<valueN>]]]`.
53+
Keys specified in this document MUST only occur at most once.
54+
55+
Clients MUST ignore every token with a key that they don't understand,
56+
and MUST ignore any value in these tokens.
57+
58+
The only defined capability keys so far are:
59+
60+
* `before-connect` - if present, indicates the server supports early
61+
registration, so it MUST NOT use
62+
`FAIL REGISTER COMPLETE_CONNECTION_REQUIRED`
63+
* `email-required` - if present, registrations require a valid email address
64+
to process
65+
* `custom-account-name` - if present, the account name can be different
66+
from the user's current nickname
67+
68+
### Commands
69+
70+
REGISTER <account> {<email> | "*"} <password>
71+
72+
The `REGISTER` command informs the server of a request to register
73+
an account named for the current nick of the requestor.
74+
75+
If `<account>` is `*`, then this value is the user's current nickname.
76+
If the server advertises the `custom-account-name` key, then this desired
77+
account name can be different from the user's current nickname.
78+
79+
The `REGISTER` command MAY be sent at any point during the connection
80+
that the client has a valid nickname.
81+
If the client sends `REGISTER` before completing connection registration,
82+
and receives a `FAIL REGISTER COMPLETE_CONNECTION_REQUIRED`, it SHOULD make
83+
a second attempt after it receives the welcome message.
84+
85+
VERIFY <account> <code>
86+
87+
The `VERIFY` command completes a registration that required verification
88+
(eg. via email or CAPTCHA).
89+
90+
### Responses
91+
92+
REGISTER SUCCESS <account> <message>
93+
VERIFY SUCCESS <account> <message>
94+
95+
Sent by the server when the `REGISTER` or `VERIFY` fully succeeded, and no
96+
further action is needed.
97+
Afterward, the client is assumed to be authenticated to the `<account>`
98+
as if it used SASL.
99+
100+
REGISTER VERIFICATION_REQUIRED <account> <message>
101+
102+
Sent by the server as a response to `REGISTER` when further action is required
103+
to complete registration of the `<account>`, as explain in the human-readable
104+
`<message>`.
105+
106+
FAIL REGISTER ACCOUNT_EXISTS <account> <message>
107+
108+
Sent by the server as a response to `REGISTER` when the client tried to register
109+
while using a nick that is not available as a new account's name
110+
because someone already registered it.
111+
112+
The server MUST NOT send this response before the client sent a `NICK` command.
113+
114+
The client MAY try registering again later.
115+
Clients should not automatically retry immediately without changing
116+
their nickname or waiting.
117+
118+
FAIL REGISTER BAD_ACCOUNT_NAME <account> <message>
119+
120+
Sent by the server to indicate that the desired account name is invalid or
121+
otherwise restricted/disallowed. The message should tell the user how or why
122+
the desired name has been rejected.
123+
124+
FAIL REGISTER ACCOUNT_NAME_MUST_BE_NICK <account> <message>
125+
126+
Sent by the server to indicate that the desired account name does not match
127+
the user's current nick, when it must match.
128+
129+
FAIL REGISTER NEED_NICK * <message>
130+
131+
Sent by the server if the client sends `REGISTER` before sending a NICK command.
132+
This is only possible in setups that advertise the `before-connect` key.
133+
134+
FAIL REGISTER ALREADY_AUTHENTICATED <account> <message>
135+
FAIL VERIFY ALREADY_AUTHENTICATED <account> <message>
136+
137+
Sent by the server if the client is already authenticated.
138+
139+
FAIL REGISTER WEAK_PASSWORD <account> <message>
140+
141+
Sent by the server if the password is considered too weak.
142+
143+
The client MAY try registering again.
144+
145+
FAIL REGISTER UNACCEPTABLE_PASSWORD <account> <message>
146+
147+
Sent by the server if the password is invalid for any reason other than
148+
weakness.
149+
150+
The client MAY try registering again.
151+
152+
FAIL REGISTER INVALID_EMAIL <account> <message>
153+
154+
Sent by the server if it cannot send emails to the provided address.
155+
156+
FAIL REGISTER UNACCEPTABLE_EMAIL <account> <message>
157+
158+
Sent by the server if the email address is valid, but not available for
159+
account registration.
160+
161+
FAIL REGISTER COMPLETE_CONNECTION_REQUIRED <message>
162+
FAIL VERIFY COMPLETE_CONNECTION_REQUIRED <message>
163+
164+
Sent by the server if the client sent a `REGISTER` command before connection
165+
registration.
166+
The server MUST NOT sent these replies if it advertizes the `before-connect`
167+
key of the `draft/account-registration` capability.
168+
169+
FAIL VERIFY INVALID_CODE <account> <message>
170+
171+
Sent by the server if the `<code>` in the `VERIFY` command is invalid
172+
or expired.
173+
174+
FAIL REGISTER TEMPORARILY_UNAVAILABLE <account> <message>
175+
FAIL VERIFY TEMPORARILY_UNAVAILABLE <account> <message>
176+
177+
Sent by the server if the `REGISTER`/`VERIFY` commands are temporarily
178+
unavailable.
179+
180+
181+
# Client considerations
182+
183+
This section is non-normative.
184+
185+
Passwords are opaque byte strings. It is recommended for them to be valid UTF-8;
186+
or authentication may be impossible later (eg. with SASL PLAIN).
187+
Servers may also choose to reject any non-UTF-8 password with `UNACCEPTABLE_PASSWORD`.
188+
189+
As passwords may need to be sent in non-`authenticate` messages,
190+
like a `PRIVMSG` to NickServ), which are limited in length, clients may want to
191+
prevent or discourage users from setting passwords so long they may not fit
192+
in these messages. 300 bytes should be a safe reasonable limit.
193+
194+
195+
# Server considerations
196+
197+
This section is non-normative.
198+
199+
Server implementations should be careful not to accidentally send `INVALID_EMAIL`
200+
as a response to a valid address.
201+
202+
As passwords may need to be sent in non-`authenticate` messages,
203+
like a `PRIVMSG` to NickServ), which are limited in length, servers may want to
204+
prevent or discourage users from setting passwords so long they may not fit
205+
in these messages. 300 bytes should be a safe reasonable limit.
206+
207+
Servers should ensure that if they allow REGISTER before connection registration,
208+
this functionality cannot be used to bypass any authentication restrictions
209+
defined in the server configuration, e.g. requirements that clients send
210+
a server password with PASS.

0 commit comments

Comments
 (0)