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

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

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 
> 
>