couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <jim....@sri.com>
Subject Re: Persona and BrowserID integration
Date Mon, 29 Jul 2013 04:00:50 GMT
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" <jhs@apache.org<mailto:jhs@apache.org>>
wrote:

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 <kxepal@gmail.com<mailto:kxepal@gmail.com>>
wrote:
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 <jhs@apache.org<mailto:jhs@apache.org>>
wrote:
(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 browserid.org/verify<http://browserid.org/verify>

At this time, for #1 we host our own copy, and for #2 we outsource to
the browserid.org<http://browserid.org> web service, so that is inconsistent. I am thinking
of the following milestones:

1. Everything outsourced.
 * Link to browserid.org<http://browserid.org> for include.js
 * Call out to browserid.org<http://browserid.org> 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 gmail.com<http://gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message