RE: [legalxml-enotary] Points for the April 30 deadline

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

Title: RE: [legalxml-enotary] Points for the April 30 deadline

John,

John,

Thanks for this excellent input.  Please see my comments in-line below.

Mark Ladd

Addison/One, LLC

262-498-0850

 

mark.ladd@addison-one.com

 

-----Original Message-----
From: John Messing [mailto:jmessing@law-on-line.com]
Sent: Sunday, April 20, 2008 10:11 AM
To: legalxml-enotary@lists.oasis-open.org; Arshad Noor
Subject: [legalxml-enotary] Points for the April 30 deadline

At the last TC Meeting, a deadline of April 30 was set for suggested

changes to the deliverable that Arshad has been working on. While it was

clarified that such matters can always be raised in connection with

needed changes to the work as it progresses, presumptively consideration

of such matters could be afterwards discouraged or considered out of

order if not raised before the April 30 deadline.

{MAL: I agree.  Although the TC has worked in a very collaborative manner to-date if we don't draw certain 'lines-in-the-sand' scope creep and late arrivers could delay the project unnecessarily.  I encourage folks to comment ASAP.}

Some areas that were discussed in this context include:

1. Whether authentication of the notary was in or out of scope. My

feeling is that while it is important for notary signing applications to

authenticate notaries and to do so according to one or more standardized

ways, this feature should nonetheless be declared out of scope for this

version of the standard, which focuses principally on interoperability

of disparate cryptographic signing methods, but I welcome other views.

{MAL: I concur with your suggestion.  I see authentication of notaries as an optional concept until the infrastructure necessary to do so in real-time matures beyond its current status.)

2. Whether some of the processes of notarization should be captured as

meta-data in the standard. For example, a common law notary identifies

the signer and determines whether the act of signing appears to be

voluntary; i.e., the signer is not drunk or insane and does not appear

to be under duress. Should a determination of voluntariness be implied

from the act of notarization itself or optionally, expressly be able to

be captured in XML meta-data for the benefit of other applications?

Harry suggested the former. Unless there is a proponent of another view,

I think his position will carry as persuasive.

{MAL: I agree with Harry.  This is part of the reason certain documents require notarization in the first place.  Voluntariness, awareness and identity are assumed prerequisites of a notarial act.}

3. I have attached an image from a page of the slide show document that

Arshad provided to the group in explaining the work he has done. It

shows elements he has crafted with regard to a signed document element,

which is an integral part of the work he has done. My thought was that

the elements he has defined could include a richer XML vocabulary, which

is a refinement of his work, so that applications could use the standard

xml vocabulary in connection with electronic journal features they

probably will or do also provide to notary users.

{MAL: This is an item the full TC needs to discuss.  Is there an existing XML vocabulary that can be leveraged for these elements (eg: PRIA/MISMO, NIEM)?  What about data that is not required in a document but needs to be captured in a journal for those jurisdictions that require one?}

4. I would have the signer name broken down into first, last and middle

name elements, on the theory that it is easier for computer applications

to combine pieces of smaller units of text than to take a larger block

of text and try to break it into component pieces (concatenate strings

rather than split them).

{MAL: In the PRIA/MISMO eNotary vocabulary we did not parse names simply because in our use case there is no business process that requires or benefits from doing so.  However, I can envision use cases that might be driven or aided by parsed names so I have no objection.  As noted, concatenation is easier than parsing.}

 

5. Similarly, I would break the address into street address, postal

code, city, state or province, and country.

{MAL: Same comment as #4, above.}

6. WRT signer ID, I assume this means the hard copy identification

document or documents that the notary relied upon to establish identity.

I would have a list here, perhaps with child elements to establish the

number and issuing jurisdiction, include as options: driver's license,

national passport, state ID card, immigration document, etc.

{MAL: What are the current journal requirements today?  In my opinion the journal - not the document - is the proper place to capture this information.  And are there statutory/regulatory issues regarding the collection of personally identifiable information that need to be considered?}

7. As for signer digital certificate, I propose substituting digital

credential, with child elements that could include digital certificate,

user token, etc.

{MAL: I concur with this suggestion.}

8. Other elements: in some states a notary actually records a

fingerprint in a journal. Some existing applications also capture a

biometric signature. I suggest an optional element of a  biometric

identifier, which could include iris scan, fingerprint, handwriting

exemplar, etc. This could perhaps be combined with the element list in

no. 7 as other companion elements in the digital credential category.

{MAL: Again, this goes to the scope question.  Are journal data points in-scope or out?  Certainly an item for the TC to discuss.}

9. I encourage input from others to these and any other points so that

the TC can decide them at the next meeting and enable Arshad to move

expeditiously forward, and I particularly name as possible contributors

John Jones, Marc Aronson and any NNA representative to the TC.

Best regards.