incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <jim....@sri.com>
Subject Re: browserid support
Date Mon, 26 Dec 2011 15:36:11 GMT
Just thought I'd point out, if you didn't know already, BrowserID is still considered a Draft
prototype and all the crypto happens in JS. The actual security of this with the current JS
implementation is questionable - it was done this way for quick prototype, and may be prone
to XSS. The concept behind BrowserID that Mozilla is working on is sound and I like the federated
ID model, in that the IDP doesn't know the RP.  There are longer term intentions to exposing
a thin JS API from NSS (look at David Dahl's DOMCrypt for a prototype) because of the questionable
security risks of generating and storing private key material inside JS. I'm not sure where
they are at on this, I've not met with that team in a few months - but they may be stalling
a bit waiting on the new W3C Web Crypto XG to start making progress. 

Sent from my iPhone

On Dec 26, 2011, at 5:19 AM, Tim Kuijsten <info@netsend.nl> wrote:

> 
> 
> Op 26-12-11 03:51, Michiel de Jong schreef:
>> there are three parts to consider:
>> - the javascript shim
>> - the verifier
>> - the identity provider (whether primary or secondary)
>> 
>> the verifier is already available as a node module. this means you could
>> probably also host the javascript shim yourself, although i haven't tried
>> this. support for primary identity providers should be coming soon (i think
>> they already have it in dev, but not sure), which means you can also get
>> rid of browserid.org as a secondary identity provider.
>> 
>> I think by offline you mean only the browser and your server are involved
>> in the exchange, and not mozilla or anyone else. It will still not be
>> offline in that sense then, because your verifier will have to talk to your
>> primary identity provider.
> But what if I run this IdP myself, then it can be run in a closed network (so without
an internet connection)?
> 
>> 
>> now there are two things a person might want to implement: an IdP (identity
>> provider), or an RP (relying party).
>> 
>> IdP means that if you have a CouchDB instance on a domain name, say
>> mycouch.nl, then users at that domain become valid BrowserId logins,
>> without the intervention of browserid.org as a secondary, and without
>> relying on SMTP. So john@mycouch.nl would suddenly become a valid BrowserId
>> identity that you can use on sites elsewhere on the web - depending on the
>> _users database of mycouch.nl. This is nice. Or it will be, once we get
>> this working. IdP reference implementation will probably become available
>> in node i would expect, /but/ i'm working on configuring CouchDB in such a
>> way that it can redirect in the proper way to such a node service. Also,
>> presumably the node service will have a data backend, which you could then
>> host on CouchDB. That is, provide a BrowserId identity for each line in
>> _users. This is something I am trying to do, so if you also want to do
>> this, then let's work together.
> Sounds good. For clarification, you are dependent on the IdP to become available in order
to use all this goodness right?
> 
>> 
>> The other thing, CouchDB as a BrowserId RP, would simply be instead of
>> clicking 'login' at the bottom right in futon, there would be a BrowserId
>> sign in button there. This is nice because then people don't have to
>> remember their CouchDB password all the time. Or for that matter, their
>> password in whatever app uses CouchDB. This would have to be something in
>> front of CouchDB, which check the BrowserId assertion, and opens a session
>> - which may involve storing the plain text admin password and sending this
>> to the client, or creating a session token and staying inbetween as a
>> proxy, or creating a session token and adding this into the _users database
>> as you send it in plain text to the client. There is an interesting
>> situation here, which is that you presumably aren't using federated
>> identity in the strict sense. Probably you're not going to allow just any
>> email address onto your couch - only your own existing users. So that means
>> that even if you don't play the role of IdP, you are accepting remote
>> identities because of how they map to local identities. The CouchDB server
>> asks 'who are you'. browserid responds 'i'm john@gmail.com', and then the
>> CouchDB server says 'ah, hello john, i know you as local user
>> john@mycouch.nl, so you're welcome.' But maybe that's always the case in a
>> sense.
>> 
>> anyway, to answer your question, i think it is possible to run server-side
>> javascript on CouchDB, but i do not think it's a good idea to implement the
>> RP's verifier, nor the IdP's certifier (or whatever it's called) in that. i
>> would use the node module(s) that Mozilla (will) provide, and run a
>> combination of CouchDB and nodejs to get your stuff working.
> I would definitely prefer to run CouchDB only and not another server. In my opinion it
would be great if Jason's module [1] could be extended to act as an IdP as well. Although
I do understand there is a tendency to use Couch with Node.
> 
>> 
>> good luck, let me know your progress!
> I have some questions that came to mind after reading your post asked on the browserid
mailing list. [2]
> 
> Thanks for your detailed insights.
> 
> [1] https://github.com/iriscouch/browserid_couchdb
> [2] http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/5d864d3a127742cf#
> 
>> 
>> Cheers,
>> Michiel
>> 
>> On Mon, Dec 26, 2011 at 9:19 AM, Tim Kuijsten<info@netsend.nl>  wrote:
>> 
>>> I'd like to run an offline (so no network dependencies on mozilla)
>>> browserid server in couch and was wondering if anyone has this already
>>> accomplished. If my understanding is correct, it's only possible to run any
>>> server-side code in erlang and not in javascript (so unfortunately I cannot
>>> build it myself yet).
>>> 
>> 

Mime
View raw message