[legalxml-courtfiling] Agenda for November 5th conference call

[John Greacen <john@greacen.net>]

We will meet by conference call at 3:00 pm EST on Tuesday, November 5th.

The arrangements for the call are as follows:

Conference Dial-in: 512-225-3050
Conference Guest Code: 84759#

The call is scheduled for 1 hour.

Here is a tentative agenda for the call:

1.  Review of the Boston minutes

2.  Any unfinished business on Query & Response and Court Document 1.1

3.  Status reports on
	California project - Christopher Smith
	Justice XML Object Oriented Data Dictionary Schema - Robin Gibson/Greg Arnold
	Architecture definition - Don Bergeron
	Orders of Protection prototype (using Court Document 1.1) statement of 
work - Laurence Leff

4.  Interoperability requirements for Court Filing 1.1

	As I understand the status of the discussion on the list, the latest 
proposal is to have three levels of conformance testing, combining 
levels 1 and 2 and levels 3 and 4 from the five levels as defined by 
Dallas Powell in the proposal contained at the end of this agenda.

5.  Versioning rules

	Shane has proposed that we add a third digit to our versioning 
convention.  This is his proposal:

A.B.C

A change in A represents major incompatible changes.  Prior versions are 
not compatible with current version.  Prior version evaluations and 
acceptablity tests can not apply to the current version.

A change in B implies minor changes.  Prior version are compatible with 
the current version.  Prior version evaluations and acceptablity tests 
only need to be extended for the new version's additional features.

A change in C implies DTD/Schema syntactic change only. The resulting 
XML messages do not change content or structure. The current version is
compatible with prior version.  Prior version evaluations and 
acceptablity tests are fully applicable to the current version.

Comment -- I do not believe that 1.0 and 1.1 are consistent with this 
convention.  I do not believe that 1.1 is compatible with 1.0 due to 
change from upper to lower camel case, wholesale renaming of elements, 
and inclusion of standard attributes for most elements.

6.  Ratification of list input to Robin concerning the format for our 
webpage.

7.  Participation in Joint Technical Committee on Security and in new 
Digital Signature Services Technical Committee.

8.  Designation of our products -- Court Filing 1.1, Court Document 1.1, 
and Query & Response as OASIS Committee Specifications?

9.  Upcoming meeting dates - December 11 (CMS-API-Q&R-CDC), 12, and 13 
in Las Vegas.

10.  Status of requirements for Court Filing 2.0

11.  Discussion of Court Policy -- as time permits.  The draft 
requirements document has been removed from consideration.  Do we want 
to pursue a different approach in constructing a revised requirements 
document?

12.  Adjournment

Dallas Powell's proposed five conformance levels:

EFC 1.1 Conformance levels for Interoperability testing and issues at 
each level.

It is my impression that Interoperability has multiple levels of 
success.  By breaking down each level we can determine where the 
failures exist and where the standard needs improvement or 
clarification.  In this document I suggest five levels of 
interoperability.  They are:
1) 
Basic validation
2) 
Communication layer
3) 
Required elements for case initiation and case updates
4) 
Required elements for filing fees
5) 
Security Model


Level 1 Basic Validation
Objective:  Make sure document instances validate when exchanged from 
one system to another on a DTD level and Base64 encoding level.
. 
Make sure that the XML document instances validate against the reference 
EFC 1.1 DTD.
. 
Make sure the DTD references in the document instances are installation 
independent and can function properly from one application to another 
without modification.
. 
Make sure that the base64 encoded binary blobs embedded in the document 
instances can be extracted and viewed in their native application.
Requirements:
. 
An application from each organization will generate court filings that 
conform to the ECF 1.1 DTD, embed Binary Blobs, and send the filing 
through e-mail or some other simple process to another organization. 
The receiving organization can run a validation process against the 
document instance and extract the Binary Blobs from the filing.
. 
The Binary Blobs must be tested by retrieving them into their native 
applications to verify that they are not corrupt.
Issues:
We found in the Georgia interoperability test, that the DTD references 
in the filings were frequently localized.  This means when validation 
began, referencing the DTD properly was not functioning.

Also, Base64 encoding needs to be checked with several different types 
of Binary Blobs.  During the Georgia interoperability test, some EFMs 
crashed because they were only able to process PDF documents as Binary 
Blobs.  Other applications were able to embed text files, Word, 
WordPerfect, TIFF, JPG, and other types of Blobs.  The ability to check 
to see if the base64 encoding was working was limited.

Even after an interoperability test occurs, when code is modified and 
enhanced, a test cycle should be followed to insure each level of 
conformance is met.



Level 2 Communication layer

Objective: Make sure each EFM and EFSP can send and receive all 
communications.
. 
Define the method for sending a court filing from an EFSP to an EFM
. 
Define the responses from an EFM to an EFSP
. 
Determine that each party can use Secure Sockets during the communication.
Requirements:
. 
An application from each organization will generate court filings that 
conform to the ECF 1.1 DTD, embed Binary Blobs, and send the filings 
through the internet to an IP address of another organization.
. 
The receiving party must be able to respond based on the parameters 
defined in the test to the sending party.
. 
The sending party must be able to accept all responses returned by the 
receiving party based on a given submission.
. 
Server Certificates must be installed to support SSL.  They can be 
self-signed certificates for the test.
Issues:
We found in the Georgia interoperability test, that it took time to get 
each application to post information from an EFSP to an EFM properly. 
Just knowing the IP address was not enough.  Also, the response packages 
were not consistent.  At this level of testing you begin to get into 
some court specific issues.  That is to say, once court policies are in 
place, there may be differences that force each EFSP to code special 
processes for each court responses.  I realize that this is not what we 
want, but until we can prove that court policies do not conflict, it 
will be difficult to implement an interoperability test that crosses 
court boundaries with live filings.

Certainly we can dummy a system that will interoperate, but that does 
not mean the court will actually allow filings based on the test.

Here is an example of the communication responses the EFM returns to the 
EFSP currently in the Utah system.
1) 
we acknowledge that we received the submission.  This means:
a) 
that the package was a valid ECF envelope,
b) 
that the source was an authorized EFSP
c) 
that the transmission has not been altered,
d) 
that the certificates of individual digital signatures in the filing 
were valid.
2) 
When we extract the information
a) 
and update the CMS
b) 
we wait for a response from CMS
c) 
we then send  a response saying that we are processing the document.
3) 
Then we query the credit card process
a) 
to authorize and charge for the filing.
b) 
We wait for the authorization code to come back.
c) 
We then update the CMS to load the payment information.
d) 
We then load the DMS with the entire envelope, the lead document and all 
attachments.
e) 
We then create an XML document and a printable document that contains 
the case number, the judge assigned, authorization code from the credit 
card, the case title, (the case title is generated by the CMS in this 
case but the attorney needs to know this) and any other information the 
court wants to include.  The XML documents we return in the receipt make 
it possible for the attorney to automate his CMS and DMS at his 
facilities.  We also include information in the receipt to create 
indisputable evidence that the receipt is bound to the submission.   The 
court digitally signs the receipt and responds to the sending unit with 
this information.   This response requires a court-filing envelope with 
embedded documents to be sent to the sending party.
Note: The CMS, DMS, and Credit processing are all on different servers 
under the control of different people so we do not feel it was 
reasonable to wait for all stages to be processed before sending a given 
response.   We provide progress reports.


Level 3 Required elements for case initiation and case update functions
Objective:
. 
Define what elements are required for case initiation
. 
Define what elements are required for case update
. 
Define what elements are optional for a given CMS
. 
Define what elements are excluded for a given court
. 
Test to insure that the EFM can be identified the lead document and all 
attachments
. 
Test to insure that the information for processing all attachments 
automatically is included.
Requirements:
. 
An application from each organization will generate court filings that 
conform to the ECF 1.1 DTD, embed Binary Blobs, and send the filing 
using the HTTP methods of communication to an IP address of an EFM.  The 
receiving EFM must be able to process all required and optional elements 
defined in the test and automatically load the CMS.
Issues:
This level of conformance further extends what each court requires to 
initiate and update filings into a case management system.  This does 
not require a live case management system, but it does require the 
elements have valid data in them so the CMS can be loaded.  It is 
unclear whether the ECF 1.1 interoperability test must force the update 
of the CMS or whether such a test should be designed by the CMS API 
conformance test.

In addition, we see that Washington King County embeds all documents and 
attachments inside of a PDF document.  That implies that they require a 
PDF document as the lead document, but it is not possible to tell from 
what I have read if they can identify what additional documents are in 
embedded in the PDF document with the lead document.

In Utah with case initiation of civil cases regarding bad debt, defaults 
on loans and similar types of cases, the clerks of the court have 
requested that initial filing can include the summons if it has already 
been serverd, and information about the summons.  This means that we 
need to know whether or not the summons is included in the filing and 
automatically update the CMS with the proper data.


Level 4 Required elements for filing fees
Objective: make sure fees are coordinated amount vendors and collected 
properly
. 
Define what elements are required for fee processing
. 
Define what elements are required to update to CMS
. 
Define how to exchange the fees between multiple systems
Requirements:
. 
An application from each organization must be able to process the fee 
collection as defined in the interoperability test.

Issues:
This level of conformance is very dependent on each court and what they 
will allow.  Each court must determine the business model they are 
willing to support for collecting filing fees and whether or not they 
will allow transaction fees.  This level of interoperability will likely 
demonstrate differences between courts.

For example, Utah mandated that all attorneys in the state must be able 
to use an electronic filing system at no cost to the attorney.  The 
legislation dictates the filing fees, and if the court installs an EFM, 
there must exist an interface for all attorneys to file without cost, 
and an API including the security model that is open, so that developers 
can create software and configure their system with the court 
implementation so that they can communicate.  This means the courts can 
sponsor a free interface for filing, while at the same time an ASP can 
provide an interface, and in addition an attorney can purchase or create 
their own software to install at their facilities.  This allows the 
attorney to automate their process just as the courts automates their 
system.

Most vendors model their business to provide a free EFM.  That does not 
mean the cost to integrate the EFM to the CMS and DMS is free.  It means 
that the use of the EFM does not require a fee per filing.  In this 
situation, when a vendor provides an EFM they depend on transaction fees 
per case filing, or some sort of control over a fee based process in 
order to support the EFSP.  An example of a controlled fee other than a 
transaction charge is where the vendor requires that all summonses are 
ordered through a vendor controlled process.  These fees for the summons 
are shared between the EFSP and the agency that serves the papers to the 
individual.

The ASP model for is seriously damaged when attorneys can install 
software at their facility that communicates directly to the courts.  We 
have found that in certain types of filings are dominated by a few legal 
firms.  For example, in Utah there are approximately 10 legal firms that 
file 80% of the debt collection cases.  Our experience suggests that 
these firms are eager and willing to install software within their 
automation process that communicates to the courts.  If only 20% of the 
cases then use the EFSP for access, the amount of fees collected will 
not support the EFSP nor the value they created when installing the EFM.

  Some of the questions that arise with fees are:
. 
Does the courts collect the court fees at their server?
. 
Can the EFSP sustain their business model if the court allows attorneys 
to install their own software?
. 
Does the EFSP collect their fees as well as the court filing fee?
. 
Will the court limit how many EFSP providers or attorneys can 
communicate with the court?

In addition to these issues we felt there is another issue regarding 
credit card information.  We felt the credit card information needed to 
be secured.  Even though the suggested level 2 conformance testing uses 
SSL to communicate, Utah has chosen to store the entire envelope for 
long term evidence of the submission.  The envelope is stored in the DMS 
and the appropriate files are extracted for viewing.  Our concern here 
is that once the envelope is stored where hundreds of clerks, staff 
members, and judges can view the submission, the credit card information 
could be exposed to many people.  Because of this, we determined to 
implement a security layer on this data.  We use asymmetric key pair 
encryption to encrypt the credit card field and base64 encoded that 
field with the results. Using this method we are able to limit the 
accessibility of the credit card information to people that have access 
to the private key installed on the server where the decryption takes 
place.  In addition to access to the private key, the ability run a 
function that can un-encode and  decrypt the field decreases the chances 
that unauthorized people will access the information.   This creates a 
much less likely chance that the credit card information will be abused, 
yet at the same time, the processing server can automatically process 
the data.

For interoperability testing we can set up a server that does not secure 
the credit card information, but we do not want live filings to be 
stored with credit card information exposed to so many people.

Level 5 Security Model
Objective: The EFM must determine that all filings are submitted by a 
valid EFSP authorized to sent envelopes.
. 
Determine that the envelope came from an authorized source
. 
Determine that the envelope has not been tampered with
Requirements:
. 
Because this is not included in the standard at this time it is 
completely dependent on the existing court implementation.
Issues:
At this time they are proprietary.  If we set up an interoperability 
test server it would not include this layer.


-- 
John M. Greacen
Greacen Associates, LLC
HCR 78, Box 23
Regina, New Mexico 87046
505-289-2164
505-780-1450 (cell)
john@greacen.net