[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Points for the April 30 deadline
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] John, John, Thanks for this
excellent input. Please see my comments in-line below. Addison/One, LLC 262-498-0850 mark.ladd@addison-one.com -----Original
Message----- 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]