[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Points for the April 30 deadline
Just an FYI on the PRIA/MISMO vocabulary. While the
current standard (v2.4.1) does not include parsed name fields for the notary,
version 3.x accommodates both parsed and unparsed names – even in the
case of the notary. I’m attaching the current standard for everyone’s
reference. The architecture of version 3.x will be element oriented
rather than the attribute orientation of the current standard – but the
data fields themselves should be fairly consistent. From: Rolly Chambers
[mailto:rolly.chambers@tprr.com] I concur with the comments of
John and Mark below. With regard to items 3 (richer XML vocabulary) and 4 (XML
elements for first, middle, and last names) and 5(XML elements for street,
postal code, city, state, country), there are many existing XML vocabularies
that such elements can be included from. I lean toward making use of an
existing XML vocabulary instead of rolling our own. NIEM (US Dept of Homeland Security
and USDOJ) or UBL (Oasis Uniform Business Language) are a couple of
possibilities. That the PRIA/MISMO XML vocabulary doesn’t include various
“name” elements would weigh against including it for an eNotary
standard. I took Arshad’s eNotary examples to be illustrative of the
data to be marked up and not a proposal for specific XML element names. Rolly Chambers Taylor Penry Rash & Riemann PLLC 704-424-2900 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]