It would, but then you also need to be logged in.. Which I guess sometimes is what you want and sometimes not. If you're not logged in the validation function doesn't have access to your userCtx.
--Albin Jan Bot wrote: > Hi, > > Wouldn't it be possible to just store the (public) key of a user within a > userdoc (under _users)? > > Cheers, > > Jan > > On Wed, Jul 4, 2012 at 9:31 PM, Bernhard Gschwantner > <[email protected]>wrote: > >> If you are the only one controlling the keys, a really nice approach for >> managing the keys is with (the original python) couchapp: just store each >> key as a single .json file in a subfolder, and couchapp takes care of >> encoding each key as a property of the design doc. From >> validate_doc_update, you can access the whole design doc via the this >> keyword. So this input: >> >> public_keys >> Alice.json: ...public key as a string... >> bob.json: ...bob's key.... >> >> Should be accessible in the validate function like this: >> >> var keys = this.public_keys; >> keys.forEach(function(key){...}) >> >> I'm on the iPad, so also a bit brief... ;-) >> >> Bernhard >> >> -- >> >> Bernhard Gschwantner >> Unser Wein G&U OG >> Kirchengasse 13/7, 1070 Wien >> >> mobil: +43 (6991) 971 32 96 >> tel: +43 (1) 971 32 95 >> e-mail: [email protected] <javascript:;> >> twitter: @bernharduw >> web: www.unserwein.at >> >> Am 04.07.2012 um 21:16 schrieb Simon Metson <[email protected] >> <javascript:;> >>> : >>> You could use CommonJS (http://wiki.apache.org/couchdb/CommonJS_Modules) >> to store the keys, that would make them available to views and validation >> functions, and I think is a bit more efficient than !json (because you can >> use them over multiple functions). It kind of depends on how much turnover >> you expect on the keys. >>> >>> On Wednesday, 4 July 2012 at 20:11, Albin Stigö wrote: >>> >>>> Yes, I agree with you, it can probably be done in JavaScript in a >>>> normal validation function.. The only problem is how to maintain a >>>> list of keys.. For a test version you can just have them stored along >>>> with the code in the validation doc using ie couchapp's !json macro.. >>>> But I think it would be really neat with a _keys db.. >>>> >>>> Another way of doing it, that I think could be implemented quite >>>> efficiently, is to have a separate worker process listening to changes >>>> stream and have a validation doc that marks all new docs with >>>> "verified: false. The worker process could then change this to true >>>> after it checked the signature. Sorry if I'm a bit brief but I'm >>>> typing this on an iPhone. >>>> >>>> Sendt fra min iPhone >>>> >>>> Den 04/07/2012 kl. 21.00 skrev Bernhard Gschwantner < >> [email protected] <javascript:;> (mailto:[email protected] >> <javascript:;> >> )>: >>>>> I've been following this thread and like the idea. I may be naïve or >>>>> completely wrong, but all this sounds quite easy to solve in a design >>>>> document and with pure javascript, although probably not very >> performant. >>>>> Just take jens' structure proposal and modify openpgp.js a little bit, >> put >>>>> the stuff into a validate_doc_update function, add the allowed public >> keys >>>>> to a design doc (easy with a couchapp), et voilà: you get a completely >>>>> replicable and transparent signature checker ;-) >>>>> >>>>> If I find the time tomorrow, I'll take a shot on a proof of concept. >> The >>>>> building blocks are there already... >>>>> >>>>> Cheers, >>>>> Bernhard >>>>> >>>>> Am Mittwoch, 4. Juli 2012 schrieb Albin Stigö : >>>>> >>>>>> Sounds interesting.. I think I will take this to the developers >> mailing >>>>>> list and see if I will be able to generate some interest in the idea.. >>>>>> >>>>>> Albin >>>>>> >>>>>> onsdag den 4. juli 2012 skrev Jan Bot : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This would really be a great feature: I'm using CouchDB to manage >> grid >>>>>>> compute jobs and having the ability to sign a document using a >> private >>>>>> key >>>>>>> and check it server side with the public key could really make >> couchdb >>>>>> part >>>>>>> of the grid infrastructure. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On Wed, Jul 4, 2012 at 11:17 AM, Albin Stigö <[email protected] >> <javascript:;>(mailto: >> [email protected] <javascript:;>)<javascript:;> >>>>>> <javascript:;>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Jens, thanks for the link. Did you ever finish the app where you >> were >>>>>>>> using these techniques? >>>>>>>> >>>>>>>> First I naively thought that it would be enough to hash the body of >>>>>>>> what you are going to PUT/POST and then sign that hash and include >> the >>>>>>>> signature as a custom http header. I guess this would work for >>>>>>>> verifying the data on the first post but you would not be able to >>>>>>>> verify the signature later if couchdb does any parsing of the >>>>>>>> transported data. >>>>>>>> >>>>>>>> What you are suggesting using a canonical representation of of JSON >>>>>>>> seems like a much better idea it also apparently what oauth uses. >>>>>>>> >>>>>>>> I guess this would require some hacking on couchdb. It would be >> really >>>>>>>> neat to have a _keys database much like the _users and for for >>>>>>>> documents to have a _signature field. What do you thin..? >>>>>>>> >>>>>>>> --Albin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 4, 2012 at 3:07 AM, Jens Alfke <[email protected] >> <javascript:;>(mailto: >> [email protected] <javascript:;>)<javascript:;> >>>>>> <javascript:;>> >>>>>>> wrote: >>>>>>>>> On Jul 3, 2012, at 10:01 AM, Jim Klo wrote: >>>>>>>>> >>>>>>>>>> Yes, and as a matter of fact, i just got digital signature >>>>>> validation >>>>>>>> using OpenPGP within a map function working a few minutes ago! >>>>>>>>>> Here's a link to the relevant code: >>>>>>>> >>>>>> >> https://github.com/jimklo/TheCollector/blob/master/dataservices/thecollector-resources/views/lib/sig_utils.js >>>>>>>>> As far as I can tell, this code uses a data schema where the signed >>>>>>>> contents are wrapped in some kind of OpenPGP encoding: >>>>>>>>>> var msg_list = >>>>>>>> openpgp.read_message(doc.digital_signature.signature); >>>>>>>>>> for (var i=0; i<msg_list.length; i++) { >>>>>>>>>> isValid |= msg_list[i].verifySignature(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>> >>>>>>>>> It looks like msg_list is the actual document payload, which has to >>>>>> be >>>>>>>> decoded using openpgp.read_message. >>>>>>>>> This is IMHO not a very good solution because it hides the document >>>>>>>> contents away — for example, all the map functions and any app logic >>>>>>>> >>>>>> that >>>>>>>> uses documents will have to know to call read_message, which will >> also >>>>>>> make >>>>>>>> them slower. >>>>>>>>> The schema I implemented (see my previous message) doesn't alter >> the >>>>>>>> basic document format. The signature is in a nested object but >> applies >>>>>>> >>>>>> to >>>>>>>> the entire document contents (minus the signature itself of course). >>>>>>>> There's no need to change any code that reads documents; the only >> time >>>>>>> you >>>>>>>> have to know about the signature scheme is while verifying the >>>>>>> >>>>>> signature. >>>>>>>> It's even possible to have multiple signatures on a document. >>>>>>>>> —Jens >>>>> >>>>> -- >>>>> >>>>> Bernhard Gschwantner >>>>> Unser Wein G&U OG >>>>> Kirchengasse 13/7, 1070 Wien >>>>> >>>>> mobil: +43 (6991) 971 32 96 >>>>> tel: +43 (1) 971 32 95 >>>>> e-mail: [email protected] <javascript:;> (mailto: >> [email protected] <javascript:;>) >>>>> twitter: @bernharduw <http://twitter.com/bernharduw> >>>>> web: www.unserwein.at (http://www.unserwein.at) >>>>> >>>> >>>> >>> >> >> -- >> >> Bernhard Gschwantner >> Unser Wein G&U OG >> Kirchengasse 13/7, 1070 Wien >> >> mobil: +43 (6991) 971 32 96 >> tel: +43 (1) 971 32 95 >> e-mail: [email protected] >> twitter: @bernharduw <http://twitter.com/bernharduw> >> web: www.unserwein.at >> >
