Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <52022BF0.3090204@mozilla.com>
Date: Wed, 07 Aug 2013 23:13:52 +1200
From: Francois Marier <francois@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:23.0) Gecko/20100101 Thunderbird/23.0
MIME-Version: 1.0
To: dev@couchdb.apache.org
Subject: Re: Persona and BrowserID integration
References: 
 <CACLy94XiKgjsZibTn5Mb5GKByH-3=yH5t-yOd+Ez_A+Dp3buaA@mail.gmail.com>
In-Reply-To: 
 <CACLy94XiKgjsZibTn5Mb5GKByH-3=yH5t-yOd+Ez_A+Dp3buaA@mail.gmail.com>
OpenPGP: id=378C39EB;
	url=https://people.mozilla.com/~fmarier/francois_marier.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 29/07/13 14:42, Jason Smith wrote:
> CouchDB should support disconnected operation. Where possible, we
> should be able to authenticate without depending on a third-party over
> the Internet. However I would like to achieve that by various
> milestones of partial completion.

Removing the dependency on a central third-party (Mozilla in this case)
is a great goal and it is in fact one of the goals of the Persona team
at Mozilla. We'll know that we are done with Persona when we can forget
to renew the persona.org domain and nobody complains ;)

However that is different from saying that logins should work when the
system is completely disconnected from the Internet. If you want to work
in a disconnected way, then you need to do everything yourself. You need
to force users to use your IdP, then host all of the login code
yourself. This could work within an organization's internal network, but
I don't think it should be the focus of the implementation because
that's not the common case.

The most common case would be a site that allows various users (who
should be free to choose who their identity provider is) to log into
your site. In this case, you need to be able to talk to their IdP to
check the validity of their cert.

> There are two (known) areas where my implementation relies on third parties.
> 
> 1. The include.js file
> 2. Validating the client signature over browserid.org/verify

The purpose of include.js is to check whether or not the browser has
native Persona support and if not, to setup a communication channel with
the JavaScript shim.

The JavaScript shim is hosted on Persona.org and cannot be self-hosted
because we rely on localStorage domain restrictions to keep the local
keys secure. The path towards decentralized here is for browsers to get
native support and not require the shim at all.

So a fully decentralized use case (not yet possible) looks like this:

(a) the relying party self-hosting include.js
(b) the user's browser has native Persona support
(c) the user's email is backed by a Persona IdP
(d) the relying party does its own verification of assertions

Once we have all 4 of these then there is no longer any traffic going
towards persona.org.

> 1. Everything outsourced.
>   * Link to browserid.org for include.js
>   * Call out to browserid.org for signature validation

That's also what I would recommend right now.

> 2. Erlang implementation of signature validation. This will take some
> R&D, could be a nice newbie project

What I would love to see (anybody interested should feel free to email
me) is an Erlang library to do this verification, separate from CouchDB,
so that other Erlang projects could use it.

It could start by just POSTing assertions to verifier.login.persona.org
and then later on be "upgraded" to doing its own local verification
(without changing the API). This means that anybody using it wouldn't
have to change anything in their code and would be upgraded to a more
decentralized flow automatically.

We have written a node.js library that does exactly that:

  https://github.com/chilts/browserid-verify-node

and we'll be extending it to the other languages we know.

Francois