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

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

Is there a possibility of buy-in from NASS and/or NNA? That might impact
the practicality of the goal that Arshad postulates.

> -------- Original Message --------
> Subject: Re: [legalxml-enotary] Two items for consideration by eNotary
> TC
> From: Arshad Noor <arshad.noor@strongauth.com>
> Date: Tue, August 05, 2008 4:58 pm
> To: John L Jones <jjones@arionzoe.com>
> Cc: 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>
> 
> 
> 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