ANN: BROWSER-ID a new SASL Authentication mechanism under development
alexey.melnikov at isode.com
Fri Sep 2 08:17:22 EDT 2011
Austin King wrote:
> At Mozilla, we're experimenting with a new SASL plugin for BrowserID.
> 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.
Is there a SASL-related spec for this, or at least an example of the
> 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:
> 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
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
> seems more secure than using proxy authentication. BrowserID is an
> Are there other
> valid user cases (webmail?) where this plugin could see some real
> world use? Perhaps
> 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
> Other feedback can come in bugs , pull requests, etc
>  https://browserid.org
>  http://lloyd.io/how-browserid-works
>  https://github.com/ozten/sasl-browserid/issues
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
More information about the Cyrus-devel