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

["Mark Ladd" <mark.ladd@addison-one.com>]

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