E-notarization XML specification

[G Ashton <pqrc96@yahoo.com>]

Silence on what is certified

The spec is silent on the question of whether the notaries only certifies what is contained
in the<StatutoryContent> element, or whether they also certify information in other
elements that contain information of a kind ordinarily certified, such as the
<DocumentSigner> element.

Lack of signing date

The example 3.1, and so far as I can see, the specification lacks any way to express the dates
 the document was signed by the document signers. This might be of no consequence if a
 document must be notarized to be effective, but if the notarization is optional, the document might go into effect earlier than the notarization date, but there would be no element to express
this date. 

4.4 Element <SignedDocuments> & <SignedDocument>

This section contains a note:

      Note: Current US law does not permit notarizing or witnessing more
     than one document per notarization or witnessing. If the law changes to
     permit the electronic notarization or witnessing of multiple electronic
     documents within a single notarization or witnessing act, the ENML
    schema does not need to change. Application developers who implement
    ENML must take legal requirements into account when developing their software.

This note conflates the concept of a legal document with the <SignedDocument> element.
Since a <SignedDocument> element must contain exactly one <Document> element, and
exactly one <DocumentMIMEType> element, for some choices of DocumentMimeType (such
as text/plain or image/jpeg) it would be impossible to combine different kinds of content in a
single <SignedDocument> element. What is commonly thought of as a single legal document,
eligible to be executed by a single signature and notarized by a single notarial act, might be
composed of information that some writers wish to represent by different
DocumentMimeTypes.

As an example, Alice, a photographer, wishes to obtain from Bob, a model, a notarized model
release for certain photographs, and wishes to place the photographs within the notarized
document to eliminate any possible doubt about which photos are being agreed to. Such a
single legal document could consist of three <Document> elements; one being plain text, a
second being a photo in jpeg format, and a third being a photo in gif format.

4.56 Processing Rule for ID attributes within ENML

The <NotarizedDocument> and <WitnessedDocument> document elements both require ID
attributes, and both may potentially be prepared by the document signers. The likelihood of
preparation by the document signers increases if they choose to use cryptographic signatures
rather than null signatures, because no security conscious person would perform a
cryptographic signing on a computer not under his/her control (such as the notary's computer).
This problem is minimal if the document signer's cryptographic computer can be carried to the
notary, or the notary's cryptographic computer can be carried to the document signer.
However, if the cryptographic computers cannot be brought together, the document signers will
have to prepare the documents well in advance (at least a few minutes, perhaps a few days).
 
In order to prepare and sign the document, the first document signer must assign an ID
attribute to the <NotarizedDocument> or <WitnessedDocument> document element. The
processing rules in section 4.56 require the document signer to know obscure information
about the notary, such as his/her commission number, commission expiry date, etc. The
document signer is unlikely to know this information before visiting the notary. Indeed, if there
are several notaries on duty in the establishment where the document signer personally
appears, the document signer may not know in advance which of the several notaries will
perform the notarization.

Also, in item 9 of section 4.56, the so-called epoch time (a poor choice of words) has a resolution of 1 second. Consider a scenario where many people are taking the same oath (the opening day of the state legislature, for example). The notary might gather all the required information and administer the oath, and only then create dozens of ENML documents as a batch operation. In this setting, several IDs with the same time could be created.
 
Gerry Ashton