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. 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 [email protected] 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. 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 [email protected]', and then the CouchDB server says 'ah, hello john, i know you as local user [email protected], 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. good luck, let me know your progress! Cheers, Michiel On Mon, Dec 26, 2011 at 9:19 AM, Tim Kuijsten <[email protected]> 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). >
