Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Jim Klo <jim.klo@sri.com>
To: "<dev@couchdb.apache.org>" <dev@couchdb.apache.org>
Subject: Re: Persona and BrowserID integration
Thread-Topic: Persona and BrowserID integration
Thread-Index: AQHOjAVvNLf7VqZ6C0mIooyNuKjVfZl7cCsAgAAE9AD//5NGMIAAeNYAgAC8GQA=
Date: Mon, 29 Jul 2013 15:26:34 +0000
Message-ID: <7DFA06A4-D6B3-4EBF-9C78-FCF0070ABEBA@sri.com>
References: 
 <CACLy94XiKgjsZibTn5Mb5GKByH-3=yH5t-yOd+Ez_A+Dp3buaA@mail.gmail.com>
 <CAHdjipKB_DkkJnhUvTNQd58a5xuAm6zCHifdpTCmyrRewSAjfQ@mail.gmail.com>
 <CACLy94VFt-qXGTWXBvAWMw-TrPYsmrDeaovaQwCX5GCtppKDZQ@mail.gmail.com>
 <278988D5-8E9C-46C0-BD39-A1AA28C6B15D@sri.com>
 <CACLy94WttB2ye3WEf2qKv6R3fMH=DCHigkwDQUzayvS_Mg7pNA@mail.gmail.com>
In-Reply-To: 
 <CACLy94WttB2ye3WEf2qKv6R3fMH=DCHigkwDQUzayvS_Mg7pNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E20EC5683863D643B002BBD89D1BFE7D@SRI.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On Jul 28, 2013, at 9:13 PM, Jason Smith <jason.h.smith@gmail.com>
 wrote:

> Thanks, Jim. That is basically my plan. To be clear, I would ship
> "outsourced mode" (browserid.org 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.
>=20
> 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.
>=20


Right.  The key difference from other 3-party solutions is that, once the B=
rowserID 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 an=
d countersign an assertion and hand back to them a signed response.  The cl=
ient then hands that signed response over the the RP from which the only th=
ing the RP should have to do is validate the countersigning done by the IdP=
 using the IdP's well known public certificate.=20

The challenge really is while they have their spec stored in GitHub=85 the =
protocol itself isn't well versioned IMO in that it doesn't advertise the r=
unning version and there's no way to interoperate with a specific version o=
f the protocol AFAIK. Thus keeping RP implementations in sync with producti=
on is a royal PITA - resulting in versions of the current CouchDB plugin br=
eaking 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/Brows=
erID into CouchDB - for those of us who would like a more stable provider t=
hat 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 <jim.klo@sri.com> wrote:
>> I've been in touch with the Mozilla folks off and on over this.  I've no=
t checked with them recently on this but at least for the time being, unles=
s your plan is to turn CouchDB into a full IDP and perform the JOSE/JWT ver=
ification that the client generates, you should not host the bits for Brows=
erID / 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 fr=
om Mozilla.
>>=20
>> +1 if someone wants to build a plugin that implements the full BrowserID=
 protocol inside CouchDB.
>>=20
>> Jim Klo
>> Senior Software Engineer
>> SRI International
>> p: 805.542.9330 x121
>> t: @nsomnac
>>=20
>> On Jul 28, 2013, at 8:30 PM, "Jason Smith" <jhs@apache.org<mailto:jhs@ap=
ache.org>> wrote:
>>=20
>> 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.)
>>=20
>> 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.
>>=20
>> However I think CouchDB has a moral duty to support disconnected
>> operation. So that is why both modes are in my plan.
>>=20
>> On Mon, Jul 29, 2013 at 10:12 AM, Alexander Shorin <kxepal@gmail.com<mai=
lto:kxepal@gmail.com>> wrote:
>> Hi Jason,
>>=20
>> 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?
>> --
>> ,,,^..^,,,
>>=20
>>=20
>> 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.)
>>=20
>> Credit where it's due: The initial push for Persona in CouchDB came
>> from Randall Leeds.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> There are two (known) areas where my implementation relies on third part=
ies.
>>=20
>> 1. The include.js file
>> 2. Validating the client signature over browserid.org/verify<http://brow=
serid.org/verify>
>>=20
>> 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 inconsis=
tent. I am thinking
>> of the following milestones:
>>=20
>> 1. Everything outsourced.
>> * Link to browserid.org<http://browserid.org> for include.js
>> * Call out to browserid.org<http://browserid.org> for signature validati=
on
>> 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.
>>=20
>> My definition of success:
>>=20
>> 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