couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: Persona and BrowserID integration
Date Mon, 29 Jul 2013 15:26:34 GMT

On Jul 28, 2013, at 9:13 PM, Jason Smith <>

> Thanks, Jim. That is basically my plan. To be clear, I would ship
> "outsourced mode" ( hosted JavaScript and verification)
> in a CouchDB release. It's just that I would work to get "tinfoil hat
> mode" added in for a subsequent release. Outsourced mode already
> exists (modulo a rewrite and unit tests) as a plugin, but I want to
> merge it in.
> I am not sure if I understand you exactly. Persona is a three-party
> protocol between users, relying parties (RPs) and identity providers
> (IdPs). I am talking about RP support for CouchDB. AFAIK there is a
> bit of mere-mortal cypto to do but it does not require IdP support.

Right.  The key difference from other 3-party solutions is that, once the BrowserID protocol
is up and running with a really stable release, Identity verification should be untraceable
by the IdP. BrowserID uses a model where the client generates public key material and asks
their IdP to validate and countersign an assertion and hand back to them a signed response.
 The client then hands that signed response over the the RP from which the only thing the
RP should have to do is validate the countersigning done by the IdP using the IdP's well known
public certificate. 

The challenge really is while they have their spec stored in GitHub… the protocol itself
isn't well versioned IMO in that it doesn't advertise the running version and there's no way
to interoperate with a specific version of the protocol AFAIK. Thus keeping RP implementations
in sync with production is a royal PITA - resulting in versions of the current CouchDB plugin
breaking all of a sudden because Mozilla changed something and theres no way to request the
old version of the protocol hence validation done on the RP side breaks..

I was just +1 that if someone wanted to build IdP support for Persona/BrowserID into CouchDB
- for those of us who would like a more stable provider that doesn't up and change suddenly
breaking things.  Also +1 for better RP support when Persona is 'ready'.

- JK

> On Mon, Jul 29, 2013 at 11:00 AM, Jim Klo <> wrote:
>> I've been in touch with the Mozilla folks off and on over this.  I've not checked
with them recently on this but at least for the time being, unless your plan is to turn CouchDB
into a full IDP and perform the JOSE/JWT verification that the client generates, you should
not host the bits for BrowserID / Persona inside CouchDB. If the plan is to continue to use
Mozilla as the IDP, where CouchDB is just an RP - you should just link to or cache from Mozilla.
>> +1 if someone wants to build a plugin that implements the full BrowserID protocol
inside CouchDB.
>> Jim Klo
>> Senior Software Engineer
>> SRI International
>> p: 805.542.9330 x121
>> t: @nsomnac
>> On Jul 28, 2013, at 8:30 PM, "Jason Smith" <<>>
>> My guess is "preferred" will depend on the usage type. Frankly IMO to
>> a first approximation, nobody uses disconnected operation anymore. (At
>> least, if they do, they have the resources to fork CouchDB.)
>> In practice, hosting a copy of include.js has been problematic. Logins
>> break every month or two. "Outsourced" mode will be more useful, for
>> sure.
>> However I think CouchDB has a moral duty to support disconnected
>> operation. So that is why both modes are in my plan.
>> On Mon, Jul 29, 2013 at 10:12 AM, Alexander Shorin <<>>
>> Hi Jason,
>> I think having "all in house" solution is preferred since it will
>> allow private local area networks to use such auth for CouchDB without
>> need to access some remote resources. With browserid / persona it will
>> be possible to have CouchDB as auth server for other instances, right?
>> --
>> ,,,^..^,,,
>> On Mon, Jul 29, 2013 at 6:42 AM, Jason Smith <<>>
>> (Breaking off from the "IRC meeting" thread.)
>> Credit where it's due: The initial push for Persona in CouchDB came
>> from Randall Leeds.
>> Dirkjan says to use the hosted include.js file instead of serving it
>> internally. I kind of agree, but note that CouchDB hosts its own
>> JQuery. The priority is not that we match the latest spec, the
>> priority is that people can log in.
>> 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.
>> There are two (known) areas where my implementation relies on third parties.
>> 1. The include.js file
>> 2. Validating the client signature over<>
>> At this time, for #1 we host our own copy, and for #2 we outsource to
>> the<> web service, so that is inconsistent.
I am thinking
>> of the following milestones:
>> 1. Everything outsourced.
>> * Link to<> for include.js
>> * Call out to<> for signature validation
>> 2. Erlang implementation of signature validation. This will take some
>> R&D, could be a nice newbie project
>> 3. Once Couch can do all the crypto "in-house," provide an option to
>> use either the self-contained implementation or else the
>> Internet-ready implementation. Most Persona logins will be to an
>> Internet server with a<> address.
>> My definition of success:
>> 1. Install CouchDB on a LAN
>> 2. Install a free software identity provider (IdP)
>> 3. Disconnect the LAN
>> 4. Create email accounts
>> 5. Authenticate to CouchDB over BrowserID

View raw message