Simple Authentication and Security Layer is currently defined in RFC 4422. A draft extension is particularely interesting, SCRAM.

... see also Linking, Authentication, Client development and XMPP.

SASL and PSYC

Should it make sense to use a SASL compliant procedure built into Spec:Linking? Probably. In fact it would be ideal if it were a generic authentication scheme to log into an identity (by using a context subscription protocol into an identity's channel of locations), but if in any way useful also allow a password-oriented approach to entering chatrooms or whatever context you can think of. Also logging in into multiple identities may be useful, and it may even want to happen at the same time over the same circuit. The circuit should thus remain a usage independent highway for packet routing, even if there is an authentication exchange happening between two entities at the ends of this circuit. It may also happen at any point in time since the creation of the circuit.

Fippo's SASL over IRC

fippo says: It would be nice if IRC supported SASL.

Proposed protocol including negotiation, as usually lines prefixed with C: are sent by the client, lines prefixed with S: are sent by the server.

Username for the examples is 'chris', password 'secret'

C: SASL MECHANISMS
S: SASL MECHANISMS :plain digest-md5 external

Client chooses mechanism

C: AUTHENTICATE PLAIN :Y2hyaXMAc2VjcmV0

where the data part is a base64 encoded concatenation of username, a null byte and password

If the password is valid the server will respond with

S: AUTHENTICATE OK

or, if it fails

S: AUTHENTICATE NO :some text explaining what has gone wrong

probably the answer should be a numeric reply... lynX?

<lynX> write an internet draft about it, then maybe you can assign a numeric to it  ;)

note: probably we should simply implement the ircx stuff: http://www.ignition-project.com/ircxdraft/ch03s02.html