[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Points for the April 30 deadline
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]