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

[John Messing <jmessing@law-on-line.com>]

To my recollection, journal support was an early focus of the TC's
effort. I think when Rich Hansberger was the Chair, it was the exclusive
focus, so I think it should be clearly excluded if that is the TC's
view, or else the default should be inclusion.

One of the use cases I do not see at present included in the work is the
declaration under penalty of perjury. Where does that one stand? Would
it be helpful to consider a trade-off between that use case and the
journal support?

> -------- Original Message --------
> Subject: RE: [legalxml-enotary] Points for the April 30 deadline
> From: "Mark Ladd" <mark.ladd@addison-one.com>
> Date: Fri, April 25, 2008 7:03 am
> To: "'John Messing'" <jmessing@law-on-line.com>, <dewan@speakeasy.net>
> Cc: <legalxml-enotary@lists.oasis-open.org>, "'Arshad Noor'"
> <arshad.noor@strongauth.com>
> 
> 
> This is good discussion.  I'm really glad to see it.  Here are a few
> additional thoughts from my corner of the world:
> 
> *	John makes a reasonable point regarding the role of a standard
> setting body.  If we leave things out that are clearly needed, developers
> will extend (hopefully) or ignore the standard.  Either way interoperability
> suffers.
> *	However, scope creep can be devastating to any project.  Our current
> Use Case document does not include the notary journal.  One of the early
> drafts included a section on the journal but the TC decided to remove it.
> *	As PRIA and MISMO work toward our Version 3.x standards there is
> discussion of organizing data according to parties (the notary personally),
> events (the actual signing of the document) and document data (the notarial
> certificate).  Since LegalXML's audience is broader than the real estate
> finance industry, it seems to me we might want to include journal data so as
> to avoid the pitfalls John M has set forth.
> 
> Food for thought.
> 
> 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: Thursday, April 24, 2008 9:27 PM
> To: dewan@speakeasy.net
> Cc: 'Mark Ladd'; legalxml-enotary@lists.oasis-open.org; 'Arshad Noor'
> Subject: RE: [legalxml-enotary] Points for the April 30 deadline
> 
> 
> While I might agree with David as to applications to be built around the
> standard according to policy or business dictates, I disagree as to the
> standard itself, which should support as many types of applications as
> it reasonably can. The standard can and should be neutral as to
> requirements of state law; but it should reasonably foresee and provide
> tools for solutions, rather than having to come back later because
> enough incompatible ways have sprung up so that the goal of
> interoperability has been undermined. The standard has unique technical
> features that could make e-notarization achievable as a technical feat.
> The notary elements are structured tags that developers can use, or not,
> as available tools, except perhaps for a core, which is an approach that
> maximizes chances of adoption by the software developer community. I
> think it is essential from a technical point of view to avoid leaving
> gaps in the standard which will require developers to invent profiles or
> extensions to solve basic problems. Absent standard tags with which to
> do so, the task will be frustrating from a developer's viewpoint
> rendering the standard unduly constricted, less useful, and therefore
> less desirable.
>  
> > -------- Original Message --------
> > Subject: RE: [legalxml-enotary] Points for the April 30 deadline
> > From: "David E. Ewan" <dewan@speakeasy.net>
> > Date: Thu, April 24, 2008 5:05 pm
> > To: "'Mark Ladd'" <mark.ladd@addison-one.com>, "'John Messing'"
> > <jmessing@law-on-line.com>, <legalxml-enotary@lists.oasis-open.org>,
> > "'Arshad Noor'" <arshad.noor@strongauth.com>
> > 
> > 
> > Here's my $0.01 (I'm a bit short since that trip to Vegas):
> > 
> >  
> > 
> > 1.       Whether authentication of the notary is in/out of scope - I agree
> > with John M. and Mark - it should be out of scope for the reasons they set
> > forth.
> > 
> > 2.       Whether some processes of notarization should be captured as
> > meta-data - As Harry and Mark noted, this is implicit in the overall
> process
> > and the reason for having the notary in the first place, so this sort of
> > meta-data should not be captured.
> > 
> > 3.       Vocabulary - I'm in favor of using as rich a vocabulary as
> > possible, but limiting it to only items in the document's notarization.
> In
> > other words, if data is required in the document's notarization, then the
> > vocabulary should be as rich as possible while comporting with common
> sense
> > and business practice.  However, if data is warranted for an associated
> > application, such as a journal, but not required for the document's
> > notarization itself, that data should be excluded (see number 6 below as
> > well).
> > 
> > 4.       Signer name parsing - I agree with John M. for the reasons he set
> > forth.
> > 
> > 5.       Address parsing - ditto.
> > 
> > 6.       Signer ID - this can be a thorny area.  Some time ago, Florida
> > altered its standard acknowledgement language to provide two check-off
> boxes
> > for the notary vis-`-vis identifying the signer.  The first was
> "personally
> > known" to the notary, the second was "produced documentation."  Associated
> > with the "produced documentation" box was a spot to further check off for
> > Driver's License and a blank line for the DL#.  No one thought too much
> > about it, until the mortgages with these acknowledgements were, of course,
> > appearing in the public land records. Great opportunity for the ID thieves
> -
> > name, address and DL# in one spot (if you got lucky, you'd also get the
> SSN
> > in the recorded document).  Florida has since removed the DL items, and
> now
> > just allows "documentation satisfactory to the notary" or words to that
> > effect (John Jones probably knows this by heart).  While it may do no harm
> > to list the TYPE of document produced (if any - remember that "personally
> > known to" is accepted in most if not all jurisdictions), I would not
> include
> > any identifying number.  Mark L. is right in this respect - it's the
> journal
> > where this information may/should be captured.  Additionally, if any of
> this
> > data is included in the document, even as meta-data, the document may run
> > afoul of the plethora of state laws protecting personally identifiable
> data.
> > Since these laws run the gamut as to what you can and cannot include in
> your
> > document, unless the data is required by law to be in the document, I'd
> > exclude it. For example, in NJ a document recorded in the land records can
> > only have the last THREE digits of the SSN appear in a document, and
> > authority for this is limited to forms required by taxation - all other
> > forms are not allowed to have ANY part of SSN. See number 3 above as well.
> > 
> > 7.       Signer digital certificate - I agree with John M.
> > 
> > 8.       Other elements - for the reasons I set forth in numbers 3 and 6
> > above, unless the data is required to be in the notarized document itself,
> > it should be excluded.  This type of data may be acceptable in a journal,
> > but should not be embedded in the document itself.  The whole point to
> > having a notary is to get an acceptable comfort level that signers are who
> > they say they are and are doing this act freely so that people can rely on
> > the act in the future.  In those jurisdictions (notably CA) where
> > fingerprints are recorded in a journal, the purpose is not to authenticate
> > the signer, nor to provide added assurance to folks relying on the
> notarized
> > document, but to provide (mostly poor) forensic evidence to assist in
> > prosecution in the event a fraud is detected at a later time.  In my
> > opinion, if anything, this is a "journal" function, not a "document"
> > function. 
> > 
> >  
> > 
> >  
> > 
> > David
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > From: Mark Ladd [mailto:mark.ladd@addison-one.com] 
> > Sent: Wednesday, April 23, 2008 11:56 AM
> > To: 'John Messing'; legalxml-enotary@lists.oasis-open.org; 'Arshad Noor'
> > Subject: 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.