General Remarks on OASIS XML for Notarization

This essay is about the eNotarization Markup Language (ENML) specification, Version 1.0, Draft 02 dated December 1, 2008.

Example 3.1 - eNotarized document - Single Signer & Notary with NULL Cryptographic Signatures

Silence concerning what the notary is certifying

This discussion applies equally well to several other examples. The document signer's name is given in the <DocumentSigner> element and in the <StatutoryContent> element. Other information that appears in both the <StatutoryContent> and some other element includes the notary's name and the notarization date. Clearly there is potential for these redundant values to disagree. The specification appears to offer no guidance about

which will prevail in case of inconsistency (which might have to be determined by courts on a case-by-case basis)
what elements must be displayed, for their approval, to the document signers and notaries in a conforming application
what information the notary is officially certifying. Perhaps only the text in the <StatutoryContent> is legally binding, and other names and dates are uncertified. Although the notary's signature "covers" these elements, perhaps that is only done to prevent alteration, and does not represent a certification by the notary that the content of the <NotarizationDate> element (for example) is true.

Lack of signing date

The example, 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

My specific observations about the so-called epoch contained in this section are contained in "Time and Notary XML". Other aspects are discussed here.

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.

Gerry Ashton

Home