1. Introduction
2. Description
2.1. Envelope
2.2. Translation Server
2.3. XCI Server
3. Missing Components
4. Technologies
4.1. Linux and Windows NT
4.2. Apache Web Server
4.3. Java Servlets
4.4. Open SSL/Mod SSL
4.5. XML
4.6. Digital Certificates and Signatures
4.7. Other Technologies
5. The Future
In June, 1999, the District of New Mexico asked for and received an electronic public access grant from the Administrative Office of the US Courts to develop an XCI demonstration with the goal of promoting a standard for XML court filing. The demonstration software is the culmination of this effort. It was developed by Rich Himes under the direction of Robert M. March, Clerk of Court, US District Court, District of New Mexico. Other background information can be found on the XCI Home Page.
The XCI paradigm is to provide an "electronic" front counter for the court. We (the courts) know how to deliver and receive paper documents across the front counter. Paper documents are placed on the counter by the attorney or runner, received, file stamped copies are returned, fees are paid, and so on. What we need is a relatively simple method for delivering documents electronically. Of course, there are new challenges on the Internet, but there is a large benefit. One benefit is the potential for bulk unattended electronic filing, where, for example, an agency needs to file the same document many times with only a participant name change. With the XML standard protocol, this could be accomplished off-hours by unattended software. The primary benefit, though, is the promise of increased electronic filing, which will ultimately lead to reduced cost (storage, handling, etc.), increased speed of litigation, and better service to chambers and the public.
Note that court-side and attorney-side case management are outside the scope of XCI. The proposed standard merely addresses document delivery to the court and defines a few simple inquiries. A narrow scope will help keep the standard from being bogged down in a myriad of local court issues. Its basic complexity should not exceed that of paper delivery. However, there may be future separate efforts to standardize portions of case management.
XCI design assumes that there will be a free version of electronic filing (not vendor-controlled) which we call XCI "Lite" as exemplified by this demonstration. XCI, however, is designed to allow a vendor to serve as an intermediary for value-added capabilities such as providing integrated desktop software (that is, other law practice software with an electronic filing option), guaranteed delayed delivery (i.e. if the court server is off line), document format translations, training, support, and so on.
XCI exists only as demonstration software as of this writing, but with the intent of becoming live production software with the appropriate additional development effort (see Missing Components.) Although portions of the demonstration software are near production-quality, this doesn't mean a court can install the software and be ready to electronically file. A court must consider how the filed documents and responses will fit in with the court's current case management system. There are also cultural issues which must be dealt with (are automation, operations, and chambers ready to receive and process an "electronic" document?) It is hoped that the demonstration software will help courts get past some of the concepts that may seem murky at first glance, and help uncover the issues that need to be addressed before a court can begin live electronic filing. The demonstration software can be used as a prototyping device for proposed projects, or it can form the basis of a live system.
XCI has the following basic components:
The messages currently defined in XCI include:
Following are the steps performed for an XCI electronic filing:
The envelope contains information being passed to and from the court. A filing message, for example, contains a description of the filing (document type, filers, descriptive text, etc.), the document being filed, and attachments. The confirmation of electronic filing contains the identifying information plus file stamp information (date filed, time filed, and assigned document number). The envelope also contains "to" and "from" Internet addresses which could potentially allow for a delayed response (only possible if there is a properly set up web server on the vendor or client side.)
Automation forecasters now generally agree that XML (tailored for each industry) is the future format for Internet data interchange, where HTML (hypertext markup language) rules today. However, allowing HTML provides wider compatibility with existing web browsers, and HTML support won't disappear in the foreseeable future. A translator has been provided with the demonstration software. The translation software can be bypassed if the client (or vendor) software is intelligent enough to deal with XML directly.
The XCI server software receives and transmits messages in XML format. Actually, returned messages are in XHTML format, a hybrid which is compatible with web browsers (for display) but also "smart" agents (software that can understand the content and process it), using advantages of both the XML and HTML worlds.
Data received by the XCI server must be stored somewhere for later retrieval. The demonstration software stores this data in XML files (see the Missing Components section.) It uses directory structure and XML to serve as a simple database for demonstration purposes. Incoming XML documents are verified for correct structural syntax by using a document type definition (see description in the technologies section for XML).
The demonstration software uses free and "open" (non-proprietary) components to facilitate experimentation and startups. Additional components will be required which either cost or vary according to local court automation infrastructure, so analysis is required. The demo uses XML files ("flat" files) and directory structure to simulate a database. Live systems will need to convert to a true database manager for scalability and reporting.
Login/password or client certificates are not included to simplify the demo. Login/password routines would be easy to add, but client certificates would be difficult and/or costly. The same goes for digital signatures. In addition, as of this writing the W3C and IETF organizations have a current joint effort to define the standards for XML digital signatures, so the standard is not well-defined as of this writing.
The demo doesn't address filing fees. Even though these features are not included in the demo, we have studied them and have proposed solutions, so please feel free to contact us if you have further questions.
All the technologies chosen for the demo are open standard-based and are free for download and use from the Internet.
The demonstration software uses the following core technologies
Digital certificates, digital signatures, and other suggested technologies are also discussed in this section.
The server-side software has been tested on both the Linux and Windows NT operating systems. Apache advises that their web server is better tested and more stable running on Linux. There is a lot of latitude in the choice of operating systems, because the software is platform-independent and the database server isn't required to run on the same computer.
As of this writing, the demonstration software is hosted by an Apache web server running on Linux. This combination is so stable that a reported 90% of Internet web servers are running on these platforms. Because Java Servlets are an open standard, and other web servers support the standard, a different web server can be used if it is a better fit for the local architecture. The free Apache Jserv add-on software allows Java servlet launching on the Apache web server.
The initial versions of Java were designed primarily to run within client web browsers as Java applets. Java servlets are designed to run on web servers. The JDK (Java Development Kit) used to develop the software was downloaded from Sun Microsystems, the current steward of the Java standard.
Open SSL and mod ssl are free software packages that can be added to the Apache web server to provide SSL (secure socket layer) protection. SSL is designed to defeat "man in the middle" attacks by encrypting the transmission and verifying both sides of the communication. This demonstration uses SSL, and this can be verified by observing that the secure-lock graphic on the Netscape browser is "locked". Note that the URL's have an https:// prefix (HTTP SSL) rather than the normal http://.
XML (extensible markup language) is the base enabling technology for XCI. It provides a simple way to identify pieces of a document. These pieces are easily identifiable both by a human reader and by a program. For example,
<FileStamp>
<DateFiled>Tuesday August 31, 1999</DateFiled>
<TimeFiled>10:34 AM</TimeFiled>
<DocumentNumber>3</DocumentNumber>
</FileStamp>
Everything between the begin tag <FileStamp> and the end tag </FileStamp> (the slash denotes end) belongs to the file stamp "element". This element has date filed, time filed, and document number sub-elements. Note that if this structure and naming convention are not standardized, different projects will implement this differently. For example, without the standard, other projects may call the file stamp <file_stamp>, <Filestamp>, and so on, and these systems will be incompatible with each other.
In support of XML, this demo software also uses the DOM (Document Object Model) standard and the XML Namespaces standard. XML includes the specification of DTDs (Document Type Definitions) which enforce the structure of XML documents. The demo software uses Sun's XML Parser, based on the hope that their forthcoming (as of this writing) XML standard extension will be related to the XML extensions in this implementation.
Just for comparison, below is a sample snipet of EDI (Electronic Data Interchange) from previous filing standards:
ST*176*23
BGN*00*23*990420
FGS*Document
CDS*CV*b*3H*97-00961*Forest Guardians v. US Fish and Wildlife*FC*nm
DTM*270*990420
REF*PL*0
It should be clear that this is far more difficult for humans and programs to interpret. It should be equally apparent why XML is catching on far more rapidly.
HTML is the wildly successful standard that is used by Internet browsers now, so why use XML? Both are compatible with their parent standard SGML (Standard Generalized Markup Language). HTML specializes in presenting data on a browser. XML specializes in identifying data content. Extracting data from HTML displays is called "screen scraping", and it is very difficult and error prone. For example, the number 9 appearing on a screen could mean an age, number of eggs, and so on. Humans can easily decipher the meaning from the surrounding natural language context, but natural language will always be difficult for computers to understand until they attain near-human intelligence. It is far easier for programs (and humans) to "understand" <MaxPigsPerAcre>9</MaxPigsPerAcre>. XML has about 90% of SGML capability with about 10% of the complexity, which helps explain why it has been more successful.
4.6. Digital Certificates and Signatures
The digital signature technology is a data version of a hand-written signature. It addresses the problem of authorization and authentication of an electronic document. Digital signatures should not be confused with a "graphic" signature, which is just a picture of a hand-written signature, is easily copied, and is not secure. Rather, it is a mathematical scheme in which a person holds a "private" key that allows them to sign data which can be verified by anyone who knows that same person's associated "public" key. The private key analogy to hand signatures is that only you have the style, musculature, nervous system, personality, etc. to produce your signature, and for digital signatures, only you have access to your private key. Digital signatures are used for authentication of the author and to validate that the document hasn't changed since it was produced (authentication, validation, and non-repudiation.)
Digital certificates match a person to their signature. By way of analogy, suppose you have a signed picture ID which identifies you as Harry Sig. You look like the picture, and you can demonstrate that you can write a signature that matches the one on the ID. The problem arises when someone questions whether this is your real name. A certifying agency is needed to certify that you are who you say you are. Depending on the level of security required, the certifying authority may ask you to show your birth certificate, signed social security card, your fingerprints, your tatoo, whatever, to prove you are in fact Harry Sig. The certificate authority would then sign a document with your picture and signature that you can use as certification of your identity and signature.
There is a corresponding process with digital signatures, where a certifying authority validates you are who you say you are. Then the certifying authority signs a certificate (digital certificate) that contains your identifying information and public key. Now when you sign something with your private key, someone can validate your signature using the public key on the certificate (nobody else can sign something such that the public key works), and they can validate your identity by checking the signature of the trusted certifying authority. These digital certificates are used to authenticate clients, servers, and digital signatures.
There have been many proposals for the digital certificate/digital signature infrastructure, but it is still not well defined after many years of debate. There are problems with deciding who the certifying authorities should be (there are certifying authorities that charge an annual fee for certificates, other agencies roll their own), where the information will be centralized, how certificate revocation is handled, and so on. There are other problems such as users with access to shared or multiple computers. Hopefully, a widespread accepted standard will emerge soon, such as the use of "smart" cards.
XML poses its own problems for digital signatures. A digital signature "freezes" the data stream, because a single character change will "break" the signature (basically a "hash" of the data encrypted with the private key.) As XML is transferred across different platforms, loaded to and from DOM trees, and so on, it will likely change, but retain the same meaning (semantics.) For example, white space (spaces, tabs, line feeds, etc.) are generally considered insignificant in XML, and the attributes can appear in any order. The empty <tag></tag> is semantically equivalent to <tag/> (slash at the end of the tag name.) Thus, the specification of a "canonical" (standard) form for XML is currently (as of this writing) being debated by the XML Digital Signature Working Group.
Until the infrastructure for digital signatures is set up and the issues have been resolved, the simplest approach is to authenticate using a login/password. However, this isn't as secure as using client certificates for authentication. Also, it would be better if the document could be digitally signed at the client machine, because this helps validate that the document isn't changed during transit and processing.
It is recommended that additional technologies that are required to integrate with the local architecture be open standards where possible. There is a danger of getting "locked in" to a single vendor who may jack up fees or not be able to support the court over the long haul. A future requirement to exit these arrangements can be very messy.
Open database connectivity (ODBC) or the related Java database connectivity (JDBC) should be used to access the database. This allows the court to more easily switch to another database manager in the future should technical requirements change.
The proposed standard requires further vetting by courts, vendors, and attorneys. The committees that will be critiquing this effort
include the GSU-based Legal-XML committee and the Joint Committee on Technology. The features and capabilities are expected
to evolve over time, tying into efforts to standardize case management and legal document formats. The technologies used can also
easily be expanded to include other communications such as inter and intra-agency transfers.