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

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

With regard to the biometrics issue, the BIAS TC has done a tremendous
amount of work about encoding biometrics in a standard form for
transmission via web services across the Internet. It can probably
leveraged as well. I think it may crop up in the DSS TC's work as well,
but I am not sure.

> -------- Original Message --------
> Subject: RE: [legalxml-enotary] Points for the April 30 deadline
> From: "Rolly Chambers" <rolly.chambers@tprr.com>
> Date: Fri, April 25, 2008 7:48 am
> To: <legalxml-enotary@lists.oasis-open.org>
> 
> 
> 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] 
> 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.