[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Points for the April 30 deadline
We included "Unsworn Declarations" as one of our Use Cases. Either way, I see value in including the journal elements - but that's just one man's opinion. 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: Friday, April 25, 2008 9:27 AM To: legalxml-enotary@lists.oasis-open.org Subject: RE: [legalxml-enotary] Points for the April 30 deadline To my recollection, journal support was an early focus of the TC's effort. I think when Rich Hansberger was the Chair, it was the exclusive focus, so I think it should be clearly excluded if that is the TC's view, or else the default should be inclusion. One of the use cases I do not see at present included in the work is the declaration under penalty of perjury. Where does that one stand? Would it be helpful to consider a trade-off between that use case and the journal support? > -------- Original Message -------- > Subject: RE: [legalxml-enotary] Points for the April 30 deadline > From: "Mark Ladd" <mark.ladd@addison-one.com> > Date: Fri, April 25, 2008 7:03 am > To: "'John Messing'" <jmessing@law-on-line.com>, <dewan@speakeasy.net> > Cc: <legalxml-enotary@lists.oasis-open.org>, "'Arshad Noor'" > <arshad.noor@strongauth.com> > > > 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. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]