[This local archive copy is from the official and canonical URL, http://www.nmcourt.fed.us/xci/xcispec.htm; please refer to the canonical source document if possible.]
Last Updated 3/12/99 (See Status and Modification History)
1. Introduction
2. Status
3. Requirements and Guidelines
4. Filing Scenario
5. Message Structure
5.1 General Message Structure
5.2 Filing Message
5.3 Pre-filing Message
5.4 Case Information Message
5.5 Registration Message
6. Technologies
6.1 Extensible Markup Language (XML)
6.2 Document Object Model (DOM)
6.3 Java
6.4 Digital Signatures and Certificates
6.5 File Formats
6.6 Message Delivery
6.7 Uniform Resource Locator (URL)
7. Conclusion
8. Modification History
The U. S. District Court, District of New Mexico (http://www.nmcourt.fed.us) has long been one of the nation's leading courts in electronic filing technology. As more electronic filing efforts become successful, there will be a corresponding reduction in handling of paper. This will reduce costs for storage, searching, handling, and litigation (faster turnaround for rulings). These compelling savings will eventually overcome resistance in the legal community. There are a number of efforts with different approaches, a good summary of which can be found in the Administrative Office of the United States Courts (AOUSC) executive summary from their document "Electronic Case Files in the Federal Courts: A Preliminary Examination of Goals, Issues, and the Road Ahead".
The Bankruptcy Court of New Mexico and New Mexico State Courts have joined the District Court to develop electronic filing software specific to their needs and the development teams are working together in order to provide a common interface for attorneys in the state. All three courts have committed to expanding these systems using XCI. These courts will be called "New Mexico" in this document for the sake of brevity. For a general overview of XCI, see the press release.
New Mexico attorneys and court staff are currently using web browsers to file documents along with document identifying information. After discussions with law offices and vendors, New Mexico decided that a standard interface that would allow other automated systems to file with the court (as opposed to "hands on" web browser filing) could dramatically increase the volume of electronic filing. In the court-centric view, an attorney connects to the court through the Internet and submits a pleading. From the attorney or law office perspective, however, their involvement may be with many courts. The Courts may require different software, passwords, etc. with differing levels of complexity, cost, and training requirements. A standard interface would allow vendors and law offices to develop for a common protocol, allowing attorneys to focus more on their law practice and less on software training. Additionally, court software vendors could develop court software for the common interface, resulting in reduced cost. New Mexico is developing XCI for their courts, and believes that other courts could benefit. This document proposes a standard interface based on New Mexico's existing web-based electronic filing system and important emerging technologies. It is designed to be simple enough and generic enough to be used by any court, yet flexible enough to serve the different needs of various courts.
This document is an initial draft of the XCI standard. Once the specification is sufficiently stabilized, it will be assigned a version number so that changes can be tracked.
Although there was initially a big push to get XCI off the ground rapidly, progress has been slowed substantially, primarily due to an unexpected budget shortfall at the state courts. The focus is now on format redesign and an enhanced prototype to demonstrate proof of principle (filing with multiple courts.) This standard is in the process of being modified substantially, due to some helpful advice from individuals outside the court. For example, instead of having a <request> <reply> structure, the message elements will be more explicit, for example <CourtFiling> which will allow tighter control by DTD's (Document Type Definitions). Another activity that is driving the change is the XML digital signature activity at IETF (as of this writing there were two proposals, search for "digital signature" at the IETF site.)
3. Requirements and Guidelines
These requirements and guidelines are based on New Mexico's experience and current electronic filing system features.
The interface basic requirements are:
Other features provided by New Mexico's system include:
For New Mexico, immediate indexing is important because electronically filed documents appear immediately on the case docket sheets. It was decided that a primary benefit of electronic filing was immediate availability and communication, and a review process would slow case processing considerably. However, the review process will be required for certain types of documents (e.g. those that must initially be sealed.) XCI can be used either way, but the key point is that immediate indexing implies that the attorney must supply enough information for meaningful (preliminary) docket text.
New Mexico controls the information supplied by attorneys to the extent that we believe the docket text generated from
attorney input will be sufficient as the final docket text (subject to quality control by docket clerks.) The docket text doesn't
need to be as comprehensive because the actual pleading can be viewed directly via a hyper link in the docket text. All that
is required is sufficient information to guide the reader to the pertinent document. The New Mexico committee addressing
this issue stated that the filers must be listed in the docket text. As a result, the proposed interface (like the web browser
interface) includes the selection of filers (from a list of parties the attorney represents.) In some documents, a referenced
document is selected. This information is used to generate the docket text. For example, a response docket text will become
"Response by ...<list of filers>... to ...<motion description>"
See the sample response to motion form used for web-based electronic filing.
New Mexico allows exhibits and attachments to be submitted at the same time as the main document. This capability is also provided by XCI.
In the table below, a browser based filing is compared to an XCI based filing. This table refers to a filing attorney, but there are other possibilities such as a trustee in a bankruptcy case (the term "filer" isn't used because it can be confused with the party the attorney is filing for.)
| Web Browser Filing | XCI Filing |
| Attorney brings up the court web page and selects the attorney main menu. A login name and password are entered for identification and authentication. A secure, encrypted link is created for the rest of the session.. | Vendor software attaches to the court using a secure, encrypted link. The link validates the attorney and the court. Each message below contains embedded court or attorney digital certificates and signatures which are used for authentication. |
| Attorney selects electronic filing from the attorney main menu, then selects the type of document being filed from subsequent menu levels. | Vendor software sends a message requesting menu options for a particular type of case. The vendor software is responsible for presenting menu options to the attorney. |
| Attorney is presented with a form for describing the filing and the file name of the pleading. | Vendor software requests the information required for a filing, or keeps track of the information required from previous transactions. This information is specific to an attorney, case, and document type (e.g. potential filers represented by the attorney.) At the time of the filing, the vendor software obtains the specific filing information from the attorney (e.g. actual filers.) |
| Attorney clicks the "File Documents" button. The document(s) and all identifying information are transmitted to the court. | Vendor software accepts the filing information from the attorney, doing any necessary file conversions. At some point, the vendor software transmits the filing message to the correct court. If not urgent, it could be sent during non-peak Internet hours. |
| Attorney waits for and receives a confirmation message for the filing. | Vendor software receives a confirmation message for the filing, and updates attorney records. Attorneys don't have to wait for this confirmation, but can view a report of filings with multiple courts at their leisure. It is possible that the court will delay the filing for some document types, in which case the vendor will receive a "delay" response and the actual confirmation will arrive at a later time. |
Messages to and from the court will be in XML (Extensible Markup Language) format. Messages going to the court will be called "request" messages and messages from the court will be called "response" messages. These messages will be wrapped in an "envelope" for delivery, also in XML format. The envelope contains the message which specifies either a request or a response. The envelope is used to authenticate that the message is from a filing attorney (or other submitting authority) that is recognized by the court and doesn't become a permanent part of a filing. The response will also be enclosed in an envelope signed by the court.
A brief introduction is required in order to understand this section. XML "tags" data using angle bracketed names. For example,
<city>Albuquerque</city>
Is a city element in which the city name is between the start tag <city> and the end tag </city>. This allows software to easily recognize the context of data in a document. Elements can also contain attributes, such as
<request type="filing"> filing data goes here </request>
Here the "type" is an attribute of the request element with the value "filing". An "empty" tag (which may contain attributes) acts as both an start and a end tag and is specified by putting the slash before the closing angle bracket, such as <filers/>. Tag pairs (elements) may be nested within other tag pairs, but they must not overlap. In this document, italicized text in elements will represent generic pieces of the XML document. For example,
<signature attributes> signature </signature>
means that the specifics of attributes and signature are defined elsewhere in this document.
All messages are "wrapped" in an envelope which contains a source URL (Uniform Resource Locator) and the signed message:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<envelope>
<from> vendor URL </from>
<signed>
message
<signature attributes> signature </signature>
</signed>
</envelope>
The <?xml ...?> line is part of the XML standard and must be included as shown (it reflects the XML support level for this version of XCI.) The envelope is not a permanent part of the filing but will be used to validate and log the message. The "from" element specifies a return address for delayed response messages. The signature is a digital signature (the corresponding digital certificate is in the message - see below.) For a discussion of signatures, certificates, and their attributes, see Digital Signatures and Certificates.
The message is designed to be complete enough to be suitable for archiving. The general format is:
<message-type type="type name" sealed="yes / no" message_id="message id" other_attributes>
message data
digital certificates
</message-type>
where message-type is either "request" or "response", type name is the type of message being serviced, yes / no is either "yes" or "no", and message data is different for different message types. The message id is required and is assigned by the vendor. It must be unique for this vendor "from" URL address and be no more than 10 characters in length. It is used to match request messages with response messages (the response reflects the request message ID.) The vendor should contact the court if there are any message ID mismatches (possible security violations.) The court will reject duplicates and return an error message (this helps prevent duplicate filings.) The digital certificates are certificates that were used to digitally sign portions of the message (and the envelope, if present.)
A request message has the general format:
<request type="type name" sealed="yes / no" message_id="message id">
request data
digital certificates
</request>
A response message has the general format:
<response type="type name" status="ok / error / partial / delayed / duplicate" sealed="yes / no" message_id="message id">
<message> response textual message </message>
response data
digital certificate
</response>
A "delayed" status means that the final response is not immediate, but will be transmitted later (e.g. after court manual review.) A "duplicate" status means the request had a duplicate message ID (with one already processed) for the from URL in the request envelope. The "from" URL address of the envelope will be used as the address to send the delayed response. The response textual message is an informational message describing the action taken by the court.
The filing request is the most complex of the messages, and is based on New Mexico's web-based filing form. The general format is:
<request type="filing" sealed="yes / no" message_id="message id">
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<case>
<id> case identification in court format </id>
<year> case year </year>
<type> case type </type>
<number> case sequence number </number>
<title> case title </title>
</case>
<document>
<type> document type </type>
<docket_template> docket entry template </docket_template>
<options> options </options>
<signed>
<file attributes> document file </file>
<signature attributes> attorney signature </signature>
other signatures as required
</signed>
</document>
<attachment>
<name> attachment or exhibit name </name>
<signed>
<file attributes> attachment file </file>
<signature attributes> attorney signature </signature>
other signatures as required
</signed>
</attachment>
other attachments as required
<certificate attributes> attorney certificate </certificate>
other certificates as required
</request>
An example of a <court> and <case> specification is:
<court>
<type>U. S. District Court</type>
<name>District of New Mexico</name>
<location><city>Albuquerque</city><state>NM</state></location>
</court>
<case>
<id>1:98cv123</id>
<year>1998</year>
<type>cv</type>
<sequence_number>123</sequence_number>
<title>Merewether v. Elfers</title>
</case>
The case number is specified in two ways for archive and portability purposes. The internal court format for a case number isn't always clear to outsiders. For example, the "2" in the New Mexico U. S. District Court case 2:96cv567 means Las Cruces, New Mexico. The "1116" in the New Mexico State Court case D1116CR0009800001 means Artesia, New Mexico. The court format is included in the message because it is more familiar to court personnel as a reference number.
The document type is the type of document, for example, "Response to Motion". This name is spelled out for archiving purposes rather than using internal codes, such as "respm". Internal codes are easily to look up in the court database.
The docket template is the suggested form structure that will be presented to the attorney by the vendor software. The template for the web-based response to motion sample mentioned above is:
<docket_template>RESPONSE by <filers/> to <refer_tos/><document/><attachments/></docket_template>
The empty tags above (<filers/>, <refer_tos/>, etc.) represent options that need to be selected by the filing attorney. The <document/> and <attachments/> options, if present, mean that a document (the actual pleading) must be included and attachments may be present. These tags are included in the template because it is possible that, in some cases, a court could consider the docket entry form as a complete filing and not require an accompanying document. Additionally, attachments may not be applicable for some document types and thus may be omitted from the template.
The options defined so far are filers, refer-to's, and additional text. The general format of these options is:
<options>
<filers type="select" option="multiple">
<filer>
<role> filer role </role>
<name> filer name </name>
</filer>
other filers as required
</filers>
<additional_text> text </additional_text>
<refer_tos type="radio">
<refer_to>
<docket_number> docket number </docket_number>
<docket_text> docket text </docket text>
</refer_to>
other refer-to's as required
</refer_tos>
</options>
Only those options actually selected by the attorney will be included in the filing (options selected are a subset of the possible options - see Pre-filing Message.)
Motion to dismiss sample options:
<options>
<filers type="select" option="multiple">
<filer>
<role>defendant</role>
<name>Lana Merewether</name>
</filer>
</filers>
<additional_text>for lack of jurisdiction</additional_text>
</options>
The additional text sample above shows the text that might be supplied for the docket template:
MOTION by <filers/> to dismiss <additional_text/> ...
that is, "motion by ... to dismiss for lack of jurisdiction".
Response to motion sample options:
<options>
<filers type="select" option="multiple">
<filer>
<role>defendant</role>
<name>Lana Merewether</name>
</filer>
</filers>
<refer_tos type="radio">
<refer_to>
<docket_number>23</docket_number>
<docket_text>MOTION by Mitch Elfers to withdraw as attorney</docket text>
</refer_to>
</refer_tos>
</options>
The filers type="select", option="multiple" means the same thing as a <SELECT MULTIPLE> in HTML (see Technologies), that is, allow multiple selections from a list (of parties). The refer_tos type="radio" corresponds to HTML's <INPUT TYPE="RADIO">, that is, select one and only one of the items with a radio button.
The filing response is the filing confirmation.
<response type="filing" status="ok / error / partial / delayed / duplicate" sealed="yes / no" message_id="message id">
<message> response textual message </message>
<document status="ok / error">
<file_stamp>
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<case>
<id> case identification in court format </id>
<year> case year </year>
<type> case type </type>
<number> case sequence number </number>
<title> case title </title>
</case>
<type> document type </type>
<description> generated docket text </description>
<docket_number> docket number </docket_number>
<date_filed> date filed </date_filed>
<time_filed> time filed </time_filed>
<court_signature attributes> court signature </court_signature>
</file_stamp>
</document>
<attachment status="ok / error">
<name> attachment name </name>
<court_signature attributes> court signature </court_signature>
</attachment>
other attachments
<court_response_document> court response document </court_response_document>
<certificate attributes> court certificate </certificate>
</response>
The response status indicates whether the filing was successful. If "ok", the filing was successful. If "error", the filing was unsuccessful. If "partial", the main document was filed successfully, but one or more attachments may have failed to be filed. If delayed, the court has elected to delay the filing response, perhaps for required manual intervention (e.g. for case opening, the court may want to assign a judge and court date before responding.) If duplicate, the filing was rejected because it has a duplicate message id (with a message already processed.) The <message> element provides a descriptive text of the filing status. The document and each attachment have an "ok / error" status to indicate success or failure during filing of those documents. Each document is signed by the court and the signatures are included. The court response document could be, for example, a list of summonses in response to a case opening, but usually this element will be empty and its content is not yet defined. The certificate is the court's certificate used to sign the documents. The file stamp is an XML version of New Mexico's digital file stamp which is their electronic replacement for the mechanical file stamp. The signature in the file stamp is the court's signature of the main document. The signature for attachments is the court signature of each attachment.
From the structure of the filing message, it is apparent that some information about the case and the document must be obtained from the court prior to the filing. Vendors could request this information at the time of the filing or elect to keep track of the necessary information themselves as the case history progresses. The pre-filing message is used to request the information at the time of the filing.
<request type="pre-filing" sealed="yes / no" message_id="message id">
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<case>
<id> case identification in court format </id>
<year> case year </year>
<type> case type </type>
<number> case sequence number </number>
<title> case title </title>
</case>
<document>
<type> document type </type>
</document>
<certificate attributes> attorney certificate </certificate>
</request>
This information is a subset of the filing request. The certificate must be that of the filing attorney (or filing authority.) The response supplies the possible selection options specific to the case, document type, and filing attorney:
<response type="pre-filing" status="ok / error / duplicate" sealed="yes / no" message_id="message id">
<message> response textual message </message>
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<case>
<id> case identification in court format </id>
<year> case year </year>
<type> case type </type>
<number> case sequence number </number>
<title> case title </title>
</case>
<document>
<type> document type </type>
<docket_template> docket entry template </docket_template>
<options> options </options>
<file type="selected / form / none"> xml form</file>
</document>
<certificate attributes> court certificate </certificate>
</response>
The docket template and options are presented to the attorney for selection during the actual filing. The certificate is the court's certificate. The XML form will be included only if the file type is "form". The form will be a standard fill-in-the-blanks form in XML format (see File Formats).
The case information message provides message components for the pre-filing and filing requests. It also provides the menu options specific to the case and, potentially, the filing attorney.
<request type="case_info" sealed="yes / no" message_id="message id">
<case>
<id> case identification in court format </id>
</case>
<certificate attributes> attorney certificate </certificate>
</request>
The certificate is that if the filing attorney. The response is used to fill in other messages:
<response type="case_info" status="ok / error / duplicate" sealed="yes / no" message_id="message id">
<message> response textual message </message>
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<case>
<id> case identification in court format </id>
<year> case year </year>
<type> case type </type>
<number> case sequence number </number>
<title> case title </title>
</case>
<menu name="menu name">
sub menus or document types
</menu>
<certificate attributes> court certificate </certificate>
</response>
The court and case number elements are fleshed out by this request and should be used as-is to prevent inconsistencies. The certificate is the court's certificate. The menus element provides a list of filing options available to the attorney for this case type. For example:
<menu name="Motion Packet">
<menu name="Motions">
<document_type>Unopposed Motion</document_type>
<document_type>Motion for Leave to</document_type>
<document_type>Motion for Summary Judgment</document_type>
<document_type>Motion to Dismiss</document_type>
</menu>
<document_type>Memorandum in Support</document_type>
<document_type>Response to Motion</document_type>
<document_type>Reply to Response to Motion</document_type>
</menu>
The registration message is used to register an attorney (or filing authority) with the court or to register a new public key with the court.
<request type="registration" sealed="no" message_id="message id">
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<register>
<name>
<prefix> name prefix </prefix>
<first> first name </first>
<middle> middle name </middle>
<last> last name </last>
<generation> generation </generation>
<suffix> name suffix </suffix>
<bar_number> bar number </bar_number>
<court_id> court ID </court_id>
</name>
<location>
<office> office name </office>
<unit> unit name </unit>
<room> room number </room>
<address_line_1> first line address </address_line_1>
<address_line_2> second line address </address_line_2>
<address_line_3> third line address </address_line_3>
<city> city </city>
<state> state </state>
<country> country </country>
<zip_1> zip code </zip_1>
<zip_2> sub zip code </zip_2>
<phone> phone number </phone>
<fax> fax number </fax>
<e-mail> e-mail address </e-mail>
</location>
</register>
<certificate attributes> attorney certificate </certificate>
</request>
The court may find it sufficient to validate this attorney using only the certificate and be able to do this automatically. This implies that the certifying authority is known and trusted and that the unique name on the certificate is recognized (see certificate issues in Digital Signatures and Certificates.) Another possibility is that the court will decide to manually verify this applicant, say, by calling the law firm or requesting a signed document. This means a temporary response will be returned (see general message structure) and that the final response will be delayed (it will be sent to the vendor's envelope "from" URL at a later time.)
Note that the court may create its own certificate for the attorney (see Digital Signatures and Certificates). The response provides either the existing certificate or a court certificate for the attorney which must be used in all further requests representing this public key:
<response type="registration" status="ok / error / delayed / duplicate" sealed="no" message_id="message id">
<message> response textual message </message>
<certificate attributes>
attorney digital certificate
</certificate>
<certificate attributes>
court digital certificate
</certificate>
</response>
This section provides a brief introduction to the technologies used for XCI. A complete description is beyond the scope of this document, but links to sites with more comprehensive (but more technical) descriptions are provided.
For a very brief overview of XML, see Message Structure. XML became a World Wide Web Consortium (W3C) recommendation (the final step in their review process) in February, 1998. XML, like Hypertext Markup Language (HTML - also described at the W3C web site), is based on the earlier and more comprehensive Standard Generalized Markup Language (SGML). The focus of HTML is to display information on web pages. The focus of XML is to provide structure for data content. XML has most of the capability of SGML without the complexity. XML is more rigorous than HTML, and allows users and user groups to define their own markup tags, as is being done in this XCI specification. XML has recently taken the computer software industry by storm, and all the major players are developing XML-based systems or using them to enhance existing systems. As of this writing, there are not very many XML tools available, but it is expected that soon the major word processors, web browsers, and publishing tools will support it.
The structure of XML is more rigorous than HTML. Unlike HTML, an element start tag must have a matching end tag. For example, in the XML case element <case>95cv123</case>, <case> is the case element start tag, "95cv123" is the case element content, and </case> is the case element end tag. A tag can stand alone if it is an empty tag. <case/> is an empty tag which serves as both a start tag and an end tag (note carefully the difference in meaning between <case/> and </case>.) The case number is said to be "tagged" or "marked up" for easy identification by programs and search engines. An element may contain sub elements. For example,
<case><year>1998</year><number>123</number></case>
It is not necessary to put line feeds or formatting between the elements, but the examples in this documentation do so for
readability. An element may also have attributes. In the case element
<case type="civil">97-123</case>
the attribute "type" has a value "civil". This generally causes a design dilemma in XML, that is, whether the data is coded
as an attribute or as element content. In this specification, the rough guideline is that long, human-readable, or searchable
data is coded as element content, and computer processing instructions are coded as attributes. Thus
<name><first>Jack</first><last>Strong</last></name>
is preferred to
<name first="Jack" last="Strong"/>
and
<signature hash_algorithm="md5">abcd</signature>
is preferred to
<signature><hash_algorithm>md5</hash_algorithm><value>abcd</value></signature>
Please note that although elements must appear in the order shown in this specification, attributes may be in any order within an element start tag. Attribute names must be unique within an element start tag.
A document type definition (DTD) is used to enforce the structure of XML and may be used in the future for XCI. XML has other features which are beyond the scope of this discussion. For more information, see the World Wide Web Consortium (W3C) home page.
As a demonstration of the relative lucidity of the XML standard, the table below shows an example of the way a case number might be encoded for transmission in XML and in Electronic Data Interchange format (EDI Transaction Set 176.) Locally developed formats can be even more cryptic. One problem with XML is that the names for fields need to be standardized for the courts so that data searches and displays will be uniform.
| Format | Example |
| XML | <case><year>1998</year><type>civil</type><number>123</number><title>Elfers v. Merewether</title></case> |
| EDI | CDS*CV*D*3H*96-90010*Elfers v. Merewether*FC*nm |
The document object model, as of this writing, is still a World Wide Web Consortium working draft. In the DOM specification, an XML document can be loaded into a document "tree" (in computer memory), where the elements are nodes and sub-elements are sub-nodes. This tree can be easily traversed and modified using the language syntax of the DOM specification, then written to a data stream or file. New Mexico's current version of XCI uses methods based on the DOM spec to process XML documents. A de facto standard called SAX (Simple API for XML), is used to allow for different parsers of the XML data stream. Several XML parsers were tried with varying degrees of success, but the current version uses a court-written parser generated using JavaCC (Java Compiler-Compiler - a parser generator from Sun Microsystems.)
New Mexico's version of XCI is being written in Java. The language is only a few of years old. It is based on C++ and tailored for the Internet. It is object-oriented, robust, secure, portable, facilitates distributed processing, and so on. It has only recently matured to the point where it can be used in server applications such as XCI.
A digital signature depends on a technology called public key encryption. This technology is used both for encryption and digital signatures, but we will only concern ourselves with signatures in this section. A signature element in the specification tells the software which algorithms were used. For example:
<signature type="filing attorney" digest="md5" encryption="rsa" bits="128"> signature </signature>
states that the MD5 algorithm was used to create the digest which in turn was encrypted using a 128 bit RSA algorithm. The details as to which algorithms and formats will be accepted for signatures are still being researched as of this writing, but it is the method that is important for this discussion, not the specifics. The crucial point is that a document can be "signed" such that the signer can be authenticated and, at the same time, the document integrity can be validated by the technology. The steps used to create a signature are transparent to the user, in that the software handles the details.
The first thing the software does in creating a digital signature is to generate a "digest" of the document. There are several algorithms for doing this and the one used must be specified in the signature element so that the signature can be validated. The algorithm runs a mathematical "hash" on the document to produce a large number, called a digest. This digest is "unique" to the document such that if one character is changed in the document and the hash algorithm run again, the digest will have a completely different value. Saying this a different way, a digest supplied with a document can be used to verify that the document hasn't changed since the digest was run.
The second step in creating a digital signature is to encrypt this digest with the signer's private key. Anything encrypted with the signer's private key can be decrypted using that signer's public (generally available) key. Here the main point is that no other public key will work, only the signer's public key. Because the signer's public key "works", the signer's private key was used to create the signature. The private key must be kept secured, and is usually password protected.
Anyone (or any software program) wishing to validate the signature must use the signer's public key to decrypt the signature. The decrypted signature is the original digest. The hash algorithm is run against the document to get a new digest. If the new digest matches the original digest, the signature has been validated. In addition, a valid signature verifies that the document has not changed since it was signed (see digest discussion above.) Digital signatures, when the private keys are adequately protected, are considered more secure than written signatures. In particular, they validate all pages at once, whereas a written signature may appear on only the last page.
Whereas digital signatures are used to sign documents, digital certificates deal with the identity of the signer. Suppose Mary gives out her public key but claims it belongs to Bob. Mary proceeds to sign documents claiming to be Bob. Those who believe they have Bob's public key validate that it is Bob's signature, and Mary has successfully spoofed the unwary. This is the problem that digital certificates address.
A digital certificate is created by an agency known as a certification authority. The certification authority certifies that individuals and organizations are who they say they are by various means such as identification cards, signed authorizations, or, at higher security levels, biological features such as finger prints or retinal scans. The certification authority creates a digital certificate stating that the person or organization "owns" a particular public key. The certification authority then digitally signs the certificate using its own private key.
The process of signature validation now involves a third party, the certification authority. Suppose I receive a document, digitally signed by "Bob". Bob has also sent his digital certificate, which contains his name, public key, and the signature of the certifying authority. First, I would use the widely known public key of the certification authority to verify its signature on the certificate (using the techniques outlined above.) I would now know that the name on the certificate was valid (according to the certifying authority.) I would then use the Bob's public key which is inside the certificate to decrypt Bob's signature and run document digest. If the digest matches the decrypted signature, I can now be certain that Bob was the signer, and that the document hasn't changed since he signed it.
There are a number of issues that arise with certifying authorities. There are a few widely used and trusted commercial certifying authorities who charge recurring fees for the certificates they issue. There are also a number of agencies, including state governments, who are in the process of becoming certifying authorities. A company or organization can purchase software to become their own certifying authority. Sometimes these certificate authorities have their own certificates signed by higher level (more reliable) certificate authorities and have adequate controls, sometimes not. The question then becomes one of whether to trust a certifying authority (for example, what if the certifying authority's private key is compromised?). Additionally, certificates can be revoked (say, if they expire or a private key is compromised), and it may be difficult to determine if a certificate is still valid.
XCI attempts to skirt around some of the thorny issues involved with certification authorities by allowing the optional creation of a court certificate for an attorney. During the registration of an attorney, the attorney identification is supplied along with a digital certificate. The court goes through its own validation process. This could be automatic (e.g. if the supplied digital certificate is signed by a trusted certification authority or another court.) Other steps may be required by the court. For example, a call could be made to the law office, the court could ask for an accompanying hand-signed document, and so forth. The procedure would probably be similar to the one used to assign a password to an attorney. The court could generate a new attorney certificate that would encompass the attorney identifying information (from the court's perspective), along with the attorney public key (taken from the original certificate), and then digitally sign the new certificate with a court signature. This certificate would be supplied in the registration response message and used for future messages from the attorney. An attorney should be allowed multiple public keys because they may differ for different personal computers, different law offices, or different locations of that attorney. Attorneys are responsible for protecting their private key and private key password.
Currently, New Mexico accepts a secured web site login and a password in lieu of a hand-written signature for web-based electronically filed documents. A password transmitted inside an XML message isn't a good idea, but the digital certificate and digital signature replace login/password authentication in the XCI world and provide better security.
The format of a signed element in XCI is:
<signed>
<element> content being signed </element>
<signature attributes> digital signature </signature>
</signed>
where element is the name of the element. This format is used at the envelope level and the document level. Note that only the content between the start <element> tag and end </element> tag is signed (these two tags are not included in the signature computation.)
The format of the signature element is:
<signature type="signature type" content_encoding="base64" content_type="application/octet-stream"
digest="digest algorithm" encryption="encryption algorithm" bits="number of bits">
signature
</signature>
The court recognizes a few signature types, such as "court", "filing attorney", and "trustee". Other types will be allowed, such as "notary", "filer", and so on but these will be used for the attorney's record only and in general the signatures won't be validated by the court unless the court specifies otherwise. The algorithm options are being researched as of this writing, and will be detailed soon. Multiple signatures may be specified for a document (element) and will be listed together, for example:
<signature type="filing attorney" ... > ... </signature>
<signature type="notary" ... > ... </signature>
Likewise, multiple certificates in the message will be listed together:
<certificate type="filing attorney" ... > ... </signature>
<certificate type="notary" ... > ... </signature>
The format of a certificate element is:
<certificate type="certificate type" format="format"
content_encoding="base64" content_type="application/octet-stream">
digital certificate
</certificate>
Except that a court certificate doesn't need encoding so it would have the general format:
<certificate type="certificate type" format="court">
digital certificate
</certificate>
The certificate type should match the signature type so that they can be mated, e.g. "filing attorney". The format may be "court" or "x509". The court certificate would have the following format:
<certificate type="court">
<signed>
<id>
<name>
<prefix> name prefix </prefix>
<first> first name </first>
<middle> middle name </middle>
<last> last name </last>
<generation> generation </generation>
<suffix> name suffix </suffix>
<bar_number> bar number </bar_number>
<court_id> court ID </court_id>
</name>
<court>
<type> court type </type>
<name> court name </name>
<location> court location </location>
</court>
<public_key> attorney public key </public_key>
</id>
<signature type="court" other_attributes> court signature </signature>
</signed>
</certificate>
With unneeded elements excluded. The court ID is the unique court identification name (or number) for the attorney. Note that the law office and location are not included in the court certificate because the attorney may change firms. The certificate is used to identify a person, not a location.
Currently, the actual pleading being filed is in portable document format (PDF) or an XML form (see below.) PDF was released by its developer, Adobe Systems Inc., as an "open" standard. Other formats, such as Microsoft's Rich Text (RTF) are vendor proprietary formats. AOUSC and other government agencies have standardized on PDF and there is an effort to get the format accepted at NARA (National Archives and Records Administration). The important feature of PDF is that it retains (at least to a large extent), the format, not just the content, of documents. Research by AOUSC indicated that the form of the document was extremely important to attorneys. PDF works with Macintosh or Windows compatible word processors. It is installed like a printer, only it prints to a file rather than a printer device. That file is the PDF file that is electronically filed with the courts.
There is a temptation to accept proprietary formats, such as Word Perfect or Word files. The problem is that the documents will print differently on machines that have different fonts or different printers installed (the same problems will be encountered in converting documents for display on the World Wide Web.) Also, there are many different incompatible versions of these word processors, so these file formats will quickly become obsolete at the court. A vendor may wish to convert these formats to PDF for the attorney, however, for submission to the court.
One problem with PDF format is that in its native format it may confuse the XML processor. For this reason, it must be encoded. This standard specifies a base64 encoding which produces only letters (upper and lower case), numbers, and a few other symbols which don't conflict. A sample PDF element:
<file content_type="application/pdf" content_encoding="base64" source_file_path="c:\filing\motion.pdf">
file being submitted
</file>
The content_type and content_encoding attributes were lifted from the HTML (Hypertext Markup Language) and MIME (Multimedia Internet Mail Extension) standards. The file path indicates the source location of the file on the attorney's machine.
A specification for PGML (Precision Graphics Markup Language), which is based on PDF, has been submitted to the World Wide Web Consortium for consideration as a standard. PGML is expressed in XML, which would make it compatible with XCI without conversion.
Another World Wide Web Consortium proposal, XFDL (Extensible Forms Definition Language) looks promising for submission of official forms to the Court. If the document is formatted as an XFDL form rather than PDF, the question then arises about the document identifying information. If the identifying information (filers, referenced documents, etc.) is tagged in the document, must that information be repeated in the message? This specification does not assume that documents, in general, will be in a format standard enough for automatic extraction of docket text. However, the court has the option to define a docket template without options (e.g. filers) if the attorney is using a standard court form. Also, if vendors provide their own standard forms, they can extract this data from the document for the XCI message.
Secure Sockets Layer (SSL) was developed by Netscape in order to transport data across the Internet securely. It authenticates, encrypts, and maintains the integrity of the data (using techniques described in Digital Signatures and Certificates). SSL has become a de facto Internet standard. It has been adopted by IETF (Internet Engineering Task Force) and this organization will improve and transform it to a new standard called transport layer security (TLS). TLS will be backward compatible with SSL.. XCI will initially use SSL, then TLS when it becomes available.
SSL relies on digital certificates for authentication. Note that the vendor digital certificate is used to authenticate the vendor machine for the court (and the court machine for the vendor), whereas the attorney digital certificate is used to validate digital signatures.
Communication with SSL is "live", as opposed to e-mail, so that any failure can be detected immediately. An e-mail message may not be received immediately. Internet e-mail can arrive many days late, due to (perhaps) a downed server or other routing problems. The Internet tries its best to deliver messages, even with unanticipated problems, because it was designed to be fail-safe. But sometimes the delivery fails and thousands or even millions of messages are lost at once. Internet e-mail doesn't supply a receipt, so delivery status is uncertain. There are some efforts to make e-mail more reliable such as BQM (Business Quality Messaging), a joint initiative by IBM, Intel, and Microsoft (targeting "99.9%" reliability which still means 1 in a thousand messages fail),. One possibility is that the vendor could resend a message that hasn't received a response after a predetermined time (note that duplicate message ID's are rejected - see General Message Structure.) If e-mail is used, all messages should be encrypted.
A URL is used to locate objects (documents, programs, images, etc.) on the Internet. The general format, or rather the format that is pertinent to XCI is:
http://host:port/path
where "http" stands for hypertext transfer protocol, "host" is the name of a host machine, "port" is the service port number, and path is a "file" path or name path. For example, in:
http://www.nmcourt.fed.us:80/xci/index.html
www.nmcourt.fed.us is the machine name, 80 is the port, and xci/index.html is the file (or object) path.
This "address" can be used like an Internet telephone number, and is used by XCI to provide communication addresses so the court and vendor software can contact each other and exchange messages.
XML Court Interface, if adopted by courts and vendors, will accelerate the volume of electronic filing, resulting in reduced cost and litigation time. It allows vendors to incorporate electronic filing in attorney and law office support software, without getting involved with court internal automation which is vastly different from court to court. As vendors include electronic filing in their software, they will assume responsibility for attorney training and technical support. This alleviates a primary limitation for courts, that is, the inability to closely support the vast number of attorneys who will file electronically in the near future. In addition, XCI provides a design framework for courts getting involved with electronic filing. Once it is accepted in the legal community, it will provide vendors the opportunity to incorporate electronic filing in court support software, with the assurance that there are attorneys who can file to this standard interface.
08/25/98 - Original version
09/03/98 - Included a description of XFDL in the File Formats Section
03/12/99 - Added the Status section to describe the work in progress
| Back to District of New Mexico Home Page | Back to Top |