ANN: BROWSER-ID a new SASL Authentication mechanism under development

[Alexey Melnikov]

Hi Austin,

Austin King wrote:

> At Mozilla, we're experimenting with a new SASL plugin for BrowserID[1].
>
> BrowserID is a decentralized identity system that makes it possible
> for users to prove ownership of email addresses in a secure manner,
> without requiring per-site passwords[2].

Is there a SASL-related spec for this, or at least an example of the 
SASL exchange?

> I'm looking for feedback on implementing a SASL authentication mechanism.
> I've got roughly the happy case working with pluginviewer and OpenLDAP.
>
> Don protective eye-ware and visit:
> https://github.com/ozten/sasl-browserid
>
> Any feedback is appreciated, but specifically:
> * Code review / contributions
> * Preferred distribution channel
> * Licensing
> * Enterprise or Academic Use Cases
> * Next steps and Timing
>
> Once this plugin is production quality, what is the best way to 
> distribute it? Should
> we try to get it upstream into Cyrus SASL,

> downstream it into OS distributions, or
> just provide it for download from a website?

My personal preferences are to try to get it into the upstream. The next 
step down is a patch in "contrib". Separate download is of course always 
an option.

I will need to have a look at the build dependencies. Complicated 
dependencies are not a showstopper, but at least we should eliminate 
circular dependencies (if any).

> Licensing - is there any preferred licensing for the code? This 
> partially depends on
> the target distribution channel. We want to balance this decision with 
> input from
> your community. plugins_common is currently a dependency. We'll 
> re-write that
> to get it out of the repo (unless it's not an issue).

I think CMU BSD-style license is the best. Then it makes your code 
compatible with Cyrus SASL.

> Use Cases - Is this plugin worth building? We're finding we need it 
> for our LDAP
> directories which are used from web applications. Authentication using 
> SASL
> seems more secure than using proxy authentication. BrowserID is an 
> awkward
> auth mechanism in that it originates from JavaScript in web content. 
> Are there other
> valid user cases (webmail?) where this plugin could see some real 
> world use? Perhaps
> webmail...?
>
> Next Steps - I see centrally registering auth mechanisms, RFCs for 
> mechanism communication,
> etc are mentioned. Is this still common practice?

Very much so. I can help you with this as well, as I've written some 
SASL-related RFCs.

> Other feedback can come in bugs [3], pull requests, etc
>
> thanks,
> ozten
>
> [1] https://browserid.org
> [2] http://lloyd.io/how-browserid-works
> [3] https://github.com/ozten/sasl-browserid/issues 

Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov