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

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

Thank you, John.

When you say "Notary Administrators and/or Notary Organizations"
are you referring to the offices of the Secretaries of State
that administer Notaries?  Or the NNA?

The primary target audience for the iconic representation of
eNotarized documents are the Relying Parties who need to verify
eNotarized documents (and who might appreciate a consistent look-
and-feel of the verification) and not the Notaries themselves.
While Notaries will "use" the icons too - as they'll need some
visual confirmation that they've correctly eNotarized a document
- "use" of the icons by RP's will significantly outnumber the
Notaries, IMO.

Note: I'm assuming that the Conformance Tool activity has no
relevance to Notaries or to the RP's because the target audience
for the tool are software developers, implementing the eNotary
spec this TC will produce.

Arshad

John Messing wrote:
> 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
>