Re: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) -PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded

[Arshad Noor <arshad.noor@strongauth.com>]

John,

One clarification in your description in the second paragraph:

ENML would NOT include any XPath expressions. At least, that is
what I'm recommending in Appendix D; but, of course, as with 
everything in a standards group, my recommendation can be over-
ridden by a TC vote.

The reason why I am OK with the use of XPath for processing XML
(as you correctly described in the first part of your second para)
and, at the same time, against embedding XPath expressions inside
ENML documents, is simply because the current specification allows
for printing raw ENML and allowing human beings to identify what
was signed by reading the <Reference> elements in the <Signature>
block.  Even though, humans will be unable to cryptographically
verify the <SignedDocuments>, <DocumentSigners> and 
<NotaryCertificates> visually, they can at least identify the
specific elements that are covered by the <Signature> element
through the explicit ID values for each element.

With XPath, you run into the problem that different software can
choose any search string and "sign" the result.  Depending on the
XPath library implementation (which may or may not work consistently
with other XPath library implementations), one cannot tell visually
what the <Signature> block refers to in a signed document.

The explicit <Reference> elements leave no doubt about what was
signed.

However, as I stated earlier, the fact that ENML may not contain
XPath search expressions for what was signed, does NOT prevent
software developers from using XPath in their applications, even
when using ENML and/or searching for specific elements within an
ENML document.  The only part of their software that will care
about the <Reference> elements is the XMLSignature library that
verifies the <Signature> element.  And, almost all ENML software 
vendors will most likely use the Apache XML Security library; I
don't believe any of the PRIA/MISMO sotware vendors will write 
their own XMLSignature library when a free, open-source, reference-
implementation is available from Apache.

I don't believe this is a major issue for programmers; I am more
than happy to talk to anyone that has specific concerns about it.
It is my personal belief that being simple and explicit will help
avoid confusion in courts in the future - but once again, this is
my opionion, which can be over-ridden.

Arshad


----- Original Message -----
From: "John Messing" <jmessing@law-on-line.com>
To: "Arshad Noor" <arshad.noor@strongauth.com>
Cc: legalxml-enotary@lists.oasis-open.org, "Mark Ladd" <mladd@pria.us>
Sent: Thursday, December 11, 2008 7:03:10 AM (GMT-0800) America/Los_Angeles
Subject: RE: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) - PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded

I think there may be consistency between ENML, MISMO and PRIA specs,
even with X-Path if I understand the workflow correctly.

I can see where MISMO and PRIA would make use of X-Path to enable
contracting parties to select from a large number of potential clauses
and possibilities in the document generation and tweaking process. ENML
would enter the picture only after that process were complete and the
finalized documents were ready for execution. ENML then would
cryptographically sign and notarize the finalized loan/mortgage
documents including their X-Path statements. What could not happen
afterwards is a change via X-Path in the finalized and executed mortgage
and note documents.

Recording information would probably be added later, outside of the ENML
notarizations, and therefore should not affect the integrity of the
signed and notarized documents. So long as the cryptographic signatures
were not affected by the later-occurring events involved in recordation,
then the various standards should complement each other and these
workflow processes. Only in the event that recordation affected the
integrity of the already completed and cryptographically signed
documents would I envision a problem, as where a recording stamp were
"added" to a notarized deed of trust, but I assume that such a recording
stamp could be constructed as a digital wrapper around the notarized
deed of trust, including the ENML notarization and its cryptographic
protections, which to a human reader would look indistinguishable on a
monitor from a rubber stamp on paper that is encountered in the paper
world.

Hope this helps.

> -------- Original Message --------
> Subject: Re: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT
> 2) - PDF   (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> From: Arshad Noor <arshad.noor@strongauth.com>
> Date: Wed, December 10, 2008 2:48 pm
> To: Mark Ladd <mladd@pria.us>
> Cc: legalxml-enotary@lists.oasis-open.org
> 
> 
> Mark,
> 
> I just want to clarify that developers are free to use XPath in
> their applications with the use of ENML; the only thing we would
> forbid is the storage of XPath expressions *inside* ENML documents.
> 
> So, it is perfectly possible for an ENML-conformant application
> to use XPath for everything - including manipulating the ENML
> itself during processing; but when it comes time to saving the
> ENML into a Notarized/Witnessed/Apostillized document, the
> application should not store XPath expressions in the ENML; rather,
> it should use only the standard <Reference> elements as outlined in
> the spec.
> 
> While this may cause some developers a little grief, I think this
> price for avoiding legal headaches in courts is well worth it.  It's
> not as if software developers don't have other effective tools to
> address the problem - I know from experience.
> 
> Arshad
> 
> Mark Ladd wrote:
> > I apologize for being tardy in my review of these latest drafts.  I also apologize that it appears I overlooked Appendix D in my earlier reviews, as I would have raised my concerns here earlier.
> > 
> > I am aware that there is a great deal of emphasis on XPath in the upcoming Version 3 MISMO & PRIA standards.  I am not certain, however, if the proposed exclusion of XPath in ENML presents any specific barriers to adoption of the eNotary standard by developers who build applications for the mortgage and recording industries.  I need to look into this and will report back (promptly).
> >   
> > 
> > Mark Ladd
> > PRIA Consultant
> >  
> > 262-498-0850
> > mladd@pria.us 
> >  
> >  
> > 
> > 
> > -----Original Message-----
> > From: arshad.noor@strongauth.com [mailto:arshad.noor@strongauth.com] 
> > Sent: Monday, December 01, 2008 10:09 PM
> > To: legalxml-enotary@lists.oasis-open.org
> > Subject: [legalxml-enotary] Groups - ENML 1.0 Specification (DRAFT 2) - PDF (ENML-1.0-Specification-DRAFT2.pdf) uploaded
> > 
> > ENML 1.0 (DRAFT 2) in PDF.
> > 
> >  -- Arshad Noor*
> > 
> > The document named ENML 1.0 Specification (DRAFT 2) - PDF
> > (ENML-1.0-Specification-DRAFT2.pdf) has been submitted by Arshad Noor* to
> > the OASIS LegalXML eNotarization TC document repository.
> > 
> > Document Description:
> > DRAFT 2 of the eNotarization Markup Language 1.0 Specification in PDF.
> > 
> > View Document Details:
> > http://www.oasis-open.org/committees/document.php?document_id=30238
> > 
> > Download Document:  
> > http://www.oasis-open.org/committees/download.php/30238/ENML-1.0-Specification-DRAFT2.pdf
> > 
> > 
> > PLEASE NOTE:  If the above links do not work for you, your email application
> > may be breaking the link into two pieces.  You may be able to copy and paste
> > the entire link address into the address field of your web browser.
> > 
> > -OASIS Open Administration
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php