FW: [legalxml-enotary-comment] E-notarization XML specification

["Mark Ladd" <mark.ladd@addison-one.com>]

Just a reminder that we had received the comment below on the ENML standard
during the public comment period.  It's been a little while since I looked
at this, but the TC should probably review and respond in some manner.


Mark Ladd
Addison/One, LLC
262-498-0850
 
mark.ladd@addison-one.com
 

-----Original Message-----
From: G Ashton [mailto:pqrc96@yahoo.com] 
Sent: Friday, May 22, 2009 12:48 PM
To: legalxml-enotary-comment@lists.oasis-open.org
Subject: [legalxml-enotary-comment] E-notarization XML specification


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


      


-- 
This publicly archived list offers a means to provide input to the
OASIS LegalXML eNotarization TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: legalxml-enotary-comment-subscribe@lists.oasis-open.org
Unsubscribe: legalxml-enotary-comment-unsubscribe@lists.oasis-open.org
List help: legalxml-enotary-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/legalxml-enotary-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-enotary