Re: Proposal for digital signatures of documents

[Mark Hammond]

As usual, 2 seconds after I hit 'Send' I think of something else to say...
On 13/04/2009 5:16 PM, Chris Anderson wrote:

Something like this then? (also a list of signatures, here)

      {
        "_id" : "89a7stdg235",
        "_rev" : "1-26476513",
        "message" : "I said this and I meant it.",
        "date" : "2009/04/09 15:54:08",
        "author" : {
          "name" : "J. Chris Anderson",
          "url" : "http://jchrisa.net";,
          "photo" : "http://jchrisa.net/profile.jpg";
        }
        "foo" : "not signed but still a normal field",
        "signatures" : [{
          "signed-fields: [ "message", "date", "author"],
          etc as described...
        }]
     }

I've a slight concern about the name 'signatures' here - its not about 
'signatures' per-se, it's more about the assumptions *any* regular word 
implies about the 'schema' of the database trying to use this facility.

In other words, how can we be sure the field 'signatures' doesn't 
conflict with a field already in the database?

I'm not quite up on the full context of this discussion, but I see 2 
potential solutions:

* Leave it up to the app to dictate the name of the field (ie, 
'signatures' is just an example in the above, but the literal field name 
is up to the app)

or

* Invent a new naming convention for a category of fields somewhere in 
between 'reserved' (ie, those with a leading '_') and 
application-specific ones.  IOW, assuming the couch impl will not let us 
use '_signatures', use something along the lines of '.signatures' - 
something couch will not reject, but something which apps can easily 
avoid.  A leading '.' does have a certain appeal - its almost a 'hidden' 
field...

Cheers,

Mark