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