RE: [legalxml-enotary] Two items for consideration by eNotary TC

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

I think that buy-in from the notary administrators and/or the notary
organizations would be a prerequisite to such an ambitious project,
though I appreciate the vision.

> -------- Original Message --------
> Subject: Re: [legalxml-enotary] Two items for consideration by eNotary
> TC
> From: Arshad Noor <arshad.noor@strongauth.com>
> Date: Wed, August 06, 2008 8:38 pm
> To: Mark Ladd <mark.ladd@addison-one.com>
> Cc: 'John L Jones' <jjones@arionzoe.com>, 
> legalxml-enotary@lists.oasis-open.org,  'laurent liscia'
> <laurent.liscia@oasis-open.org>, 'James Bryce Clark'
> <jamesbryceclark@gmail.com>,  'Carol Geyer' <carol.geyer@oasis-open.org>
> 
> 
> These are very good questions, Mark.  I agree that Jamie should
> weigh in on the liability issue, although common-sense tells me
> that the Conformance Tool (CT) can only assert that a particular
> software implementation of the spec passed the CT's tests (that
> the documents created by the implementer's SW produced XML that
> passed the CT).  It cannot, obviously, vouch for anything in the
> eNotarization process or that bugs in the implementer's software
> cause other problems that impact the notarization/verification
> process.  That remains the responsibility of the SW vendor.
> 
> The way I see the tool working is that a SW implementation would
> implement the spec, create eNotarized documents with it, and would
> then verify the eNotarized document with the CT (which will provide
> detailed debugging output as well as the visual icon display).  The
> SW implementer would then check to see that their software goes
> through the same verification process and produces the same result,
> thus ensuring that they produce eNotarized documents that conform
> to the spec.  The CT would be like a pacing-car to make sure SW
> implementations don't get out of whack from the spec.  I don't
> believe OASIS is exposed for providing such tools, but that's for
> Jamie to determine and declare.
> 
> WRT logistics, building such a CT will not be trivial, but its not
> very difficult either.  I've written some very complex software (for
> the protocol that is being standardized in the EKMI TC) and based on
> that effort, I would estimate that a software developer could produce
> a decent CT within 3 months.
> 
> I don't believe that OASIS would be limiting market creativity; if
> that were true, then none of OASIS' standards would be implemented
> by any vendor.  Standardization, as you know, expands the market size,
> and speeds up adoption because of consistency.  Given the kinds of
> things Acrobat, Word, OpenOffice, WordPerfect and all the other
> document-software perform, the eNotarization module will be a tiny
> drop in their ocean of features/code.  Important from a legal point-
> of-view, but insignificant from a code-POV.
> 
> That said, I think OASIS should make a concerted effort to try and
> bring Microsoft, Adobe, Sun Microsystems (owner of OpenOffice), Corel
> and other document-management companies to the eNotary TC table and
> ask them to participate in this part of the process.  I believe they
> will see the wisdom of the effort once they hear the arguments.
> 
> The browser industry is plagued with these look-and-feel problems and
> I can't tell you what a headache it is for software developers who're
> trying to create a consistent L-and-F to their applications when IE,
> Firefox, Safari and Opera all do a common thing very differently.  I'm
> hoping to avoid that headache for SW developers when it comes to
> eNotarized documents.
> 
> Arshad
> 
> Mark Ladd wrote:
> > I wonder about things like:
> > 
> > Liability - what exposure is there for OASIS/LegalXML if someone relies on
> > either our conformance test or our icon only to have something go wrong.
> > How much legal infrastructure needs to be erected to mitigate that risk?
> > Does that legal infrastructure already exist?  I'd like to hear from OASIS
> > staff on this.
> > 
> > Logistics - how much technology infrastructure needs to be built to support
> > the icon idea?  Arshad compares it to SSL/TLS which, of course, seems
> > transparent to the consumer.  I don't write code for a living but I've seen
> > enough to know that some of the things that appear to be really easy from
> > the consumer viewpoint are supported by some incredibly complex technology
> > solutions.  How big a task is this to create and maintain?  Would it require
> > funding?  
> > 
> > Limiting Market Creativity - do we run a risk by specifying too much?
> > Competitive advantage drives innovation.  I think we need to be careful not
> > to over-reach.
> > 
> > None of this is meant to say I'm opposed to the proposals.  These are just
> > questions that come to my mind as I consider the ideas.
> > 
> > 
> > Mark Ladd
> > Addison/One, LLC
> > 262-498-0850
> >  
> > mark.ladd@addison-one.com
> >  
> > 
> > 
> > -----Original Message-----
> > From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> > Sent: Tuesday, August 05, 2008 6:59 PM
> > To: John L Jones
> > Cc: legalxml-enotary@lists.oasis-open.org; laurent liscia; James Bryce
> > Clark; Carol Geyer
> > Subject: Re: [legalxml-enotary] Two items for consideration by eNotary TC
> > 
> > John L Jones wrote:
> >> I may be missing something. Sometimes I'm a little slow, so please help 
> >> me understand the need for LegalXML and OASIS to provide these 2 items. 
> >> I understand there may be some utility, but are those for a standards 
> >> setting organization to provide?
> > 
> > It is not uncommon for standards organizations to provide conformance
> > testing tools.  I can't specifically point to any from OASIS because
> > I only participate in just 2-3 TC's, but I have seen such tools from
> > other standards groups in the past.
> > 
> > That said, I would like us to think of this as a quality-control tool.
> > The repercussions of the eNotary specification outside the technology
> > industry are tremendous; the visibility it will bring OASIS will be
> > huge.  The more quality we can build into the spec and conformance to
> > it, the better OASIS looks outside the technology industry.  For a
> > small investment, there will be a huge payback.
> > 
> >> How many other tools have OASIS TC's developed for performance testing? 
> >> And why is one needed specifically notary as compared to some of the 
> >> more significantly more complex specifications such as the various 
> >> security related ones? I have difficulty believing that an OASIS tool 
> >> would prevent someone from challenging a notarization if the stakes were 
> >> high enough. Then OASIS gets the opportunity to defend it's tool or 
> >> forfeit the spec.
> > 
> > The eNotary specification is a complex one, John, and does have security
> > implications in it (XML Signature).  The more important factor is that
> > there are legal implications to the specification (if they're improperly
> > implemented, or there are bugs in specific implementations).  We could
> > prevent all the legal headaches by providing the Conformance Tool. (It
> > is also a standard discipline in software development these days - to
> > build your test-cases/modules with the actual software).
> > 
> > I'm not saying that the OASIS tool will prevent someone from challenging
> > notarizations; but it will definitely help the software developers who
> > are building applications that eNotarize/verify eNotarized documents.
> > It would be a quality-assurance step in their release-process that would
> > ensure that they're in line with the spec.
> > 
> >> As for the icon I don't understand what the value of the assurance is 
> >> unless the certificate and notary information is not visible. I can't 
> >> imagine an icon by itself would suffice. If the document is wrapped in 
> >> an XML file with the notarial information it will have to have a way to 
> >> be made visible whether or not a icon is used. The icon may be useful in 
> >> alerting a viewer that a document is notarized, but it can't stand on 
> >> it's own. As was noted by Gerard Ashton the icons can be manipulated. 
> >> This idea becomes more of an document software application 
> >> implementation issue.
> > 
> > Think of the OASIS eNotarization icon as the equivalent of the "lock"
> > icon in SSL/TLS.  It is a visual indicator that the software has checked
> > the underlying components and has made a determination based on that
> > check.  No, an icon by itself will not suffice; it must be backed up by
> > the actual details (just as clicking on the SSL lock brings up all the
> > details of the digital certificate in a browser).  And no, the icon must
> > not stand on its own; it can only be displayed at the conclusion of its
> > verification process.
> > 
> > Anything can be manipulated, John.  The lock icon on a browser can be
> > manipulated by a plug-in/active-x control downloaded from the internet,
> > as can any software product's icons related to security-checks.  This
> > is a fundamental OS-security issue.  But that shouldn't prevent us from
> > providing a utilitarian function that standardizes the look-and-feel of
> > an eNotarized document.  It will eliminate one more barrier to adoption.
> > 
> > 
> >> Mr. Ashton also makes a point regarding whether or not an element in the 
> >> XSD is optional or mandatory. Unless a data point is required by all 
> >> jurisdictions it should be optional in the specification. Enterprising 
> >> developers may figure out how to customize their software to provide 
> >> state specific rules that know when to require an element and when to 
> >> omit it. But we need to ensure that all the elements are correctly 
> >> tagged with attributes to reflect this. Can we get a list of the 
> >> elements we've agreed on so we can help you decide the appropriate 
> >> attributes?
> > 
> > XML Schema implies mandatory/optional elements automatically by the
> > absence/presence of the "minOccurs" attribute: the absence of the
> > attribute implies it is mandatory.  Presence either implies optional
> > or mandatory based on the number that are required.
> > 
> > I have chosen to be explicit and specified "minOccurs" for all elements
> > so that people without XML Schema knowledge can determine (visually or
> > programmatically) if an element is mandatory or optional. For example
> > in the following elements:
> > 
> > <xsd:element
> > 	name="City"
> > 	type="tns:CityType"
> > 	minOccurs="0"
> > 	maxOccurs="1"/>
> > 
> > <xsd:element
> > 	name="County"
> > 	type="tns:CountyType"
> > 	minOccurs="1"
> > 	maxOccurs="1"/>
> > 
> > you'll notice that while the City is optional for an address, the
> > County is required (for the location of notarization).
> > 
> > So, reviewing the current XSD will tell you which are optional and
> > which are mandatory.
> > 
> > Hope that helps.
> > 
> > Arshad Noor
> > StrongAuth, Inc.
> > 
> >> -------
> >> John
> >>
> >>
> >> Arshad Noor wrote:
> >>> Gentlemen (and Carol),
> >>>
> >>> Thinking about the eNotary specification that we plan to put
> >>> out this year for electronically notarized documents, and after
> >>> some discussions with people on this topic, I believe there are
> >>> two important items of work that this TC must contemplate
> >>> producing along with the XML Schema Definition (XSD) standard.
> >>> These are:
> >>>
> >>> 1) A testing tool to test eNotarized documents for conformance
> >>> with the forthcoming OASIS standard; and
> >>> 2) Visual representation marks for eNotarized documents that
> >>>    are standardized across applications.
> >>>
> >>> The first is critical to application developers - as well as 
> >>> the courts - since there must be a single tool that can be
> >>> referenced in the event there are disputes between two different
> >>> implementations of software which deal with eNotarized documents
> >>> and that produce different results.  The standard OASIS testing
> >>> tool will allow developers to test their software implementations 
> >>> for conformance with the TC's spec BEFORE they release their SW,
> >>> thus ensuring that their software does not produce different 
> >>> results for sample eNotarized documents.
> >>>
> >>> The second is equally critical - but to end-users and relying
> >>> parties who would appreciate a consistent representation of an
> >>> eNotarized document across applications.  While software may have
> >>> passed the conformance test in #1, if each vendor chooses to
> >>> display the result of verifying an eNotarized document with its
> >>> own icons/representations, it could lead to confusion in the
> >>> industry despite the OASIS standard.
> >>>
> >>> I would propose that this TC take up these two work-items and 
> >>> create the conformance tool and visual icons so that the value 
> >>> of the OASIS eNotary standard is not diluted.
> >>>
> >>> To that extent I would also propose that, after the TC has come to 
> >>> an agreement on these work-items, it put out RFP's for the creation
> >>> of these artifacts.  The terms, ownership, licensing, etc. can all
> >>> be worked out in conjunction with OASIS staff (who are copied on
> >>> this e-mail for expediency).
> >>>
> >>> I would also recommend that, while OASIS can make the conformance
> >>> testing tool freely available to adopters, the visual icons should
> >>> be restricted for use by only OASIS members, and only if they have 
> >>> shown conformance with the tool through an independent testing 
> >>> process.  Not only does this reinforce the value of an OASIS 
> >>> membership, but it protects the "brand" of an OASIS-compliant 
> >>> eNotarized document.  For end-users who will have to deal with 
> >>> eNotarized documents in their software, seeing standardized icons 
> >>> in a consistent manner within eNotarized documents will enhance the 
> >>> value of the standard to the entire industry.
> >>>
> >>> Thoughts/Reactions?
> >>>
> >>> Arshad Noor
> >>> StrongAuth, Inc.
> > 
> > ---------------------------------------------------------------------
> > 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 
> > 
> > 
> 
> ---------------------------------------------------------------------
> 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