GEORGIA STATE UNIVERSITY ELECTRONIC COURT FILING PROJECT GSU’s E-CT-Filing project began in late 1997 as state pilot project for the purpose of applying digital signature technology to government applications. GSU’s Colleges of Law and Business partnered to complete the project. We choose electronic court filing because the application seemed natural in view of the College of Law’s participation. Very quickly, we realized that the creation of an electronic court filing system required the resolution of multiple issues beyond the use or non-use of digital signatures. One of the more significant issues is the "document format" issue. There is a many-to-many relationship between courts and lawyers. As a result, courts and lawyers need to standardize on a common document format in order to efficiently pass documents between multiple law offices and courthouses. Law offices are split about 50-50 in the use of either Word Perfect (various versions, usually older version) and Microsoft Word (usually newer versions). Courts are similar. At present, it appears that many courts will require the filing of PDF documents, since this will obviate the need to mandate a particular version of MS Word or Word Perfect. PDF, of course, is not an elegant means of passing information. The prospect of an industry-accepted Legal XML standard is much more elegant. The problem: creating the standard. Over the past year and a half the GSU project has advocated the creation and use of industry-standard legal SGML or XML DTDs. In November 1998, GSU began hosting the Legal XML Workgroup on a university listserve. Presently, our numbers are around 40-45 and are growing. We are partnered in our efforts with FindLaw (www.findlaw.com). FindLaw maintains a Legal XML web site (www.legalxml.org). Other information can be found on GSU’s E-CT-Filing web site (http://gsulaw.gsu.edu/gsuecp/). More information is available on a password protected website. Contact me if you would like to join the list and have access to the password protected website. MY BACKGROUND, INTERESTS AND POTENTIAL FOR CONTRIBUTION I am a lawyer . . . which usually receives a cheerful "boo . . . hiss" from technical folks . . . but would note that, while I do not have a technical degree, I began programming in Basic and Pascal in eighth grade. I continue to do technical work and some programming using various databases, HTML, Perl, some Java and Visual Basic, and XML. Additionally, the GSU E-CT-Filing project is currently using commercial software to implement a pilot PKI for use with a prototype electronic court filing system. On the legal side, I am co-author and reporter of the National Automated Clearing House’s CARAT Certificate Policy Guidelines, I recently co-authored amendments to Georgia’s Electronic Records and Signatures Act, I played a nominal part in Senator Abrahams recently introduced Millennium Digital Commerce Act (of which I do not necessarily approve), and I have participated in the National Conference of Commissioners on Uniform State Law drafting of its Uniform Transaction Act (of which I do not necessarily approve). (all of the above have something to do with the legal effect and validity of electronic records and signatures and/or digital signatures) A combination of both legal and technical skills, I hope, will allow me to bring a unique perspective to the creation of technical standards for signing XML documents. LIMITATION TO MY CONTRIBUTION While a combination of legal and technical skills may allow me to bring a unique perspective to this effort, it is also a limitation. My technical knowledge is not nearly as advanced as many, if not all, of the people on this list. As a result, I ask for your patience and careful explanation if and when I do not entirely grasp a technical issue. POSITION ON XML-DSIG The Legal XML Workgroup is beginning to formulate a methodology for structuring and organizing our mark-up. I have been using the following metaphor to explain our methodology: "skeleton", "meat", "brains", and "skin." SKELETON: There are various types of legal documents within the legal domain: legal letters, contracts, court filings, statutes, law reviews and journals, legal books, and treaties. Each of these document classes has a unique structure (the relationship of captions, titles, headings, paragraphs, signature blocks, etc.). Such structure exists because of the type of information in each document, the purpose of the document, tradition, etc. and we cannot expect to change the structure -- lawyers would rebel if certain documents did not continue to look (more or less) as they do on paper when created electronically. Accordingly, there is general agreement in our group that different DTDs or namespaces within the legal domain should be created for the structure of each document class. MEAT: Within the legal industry, just as in any industry, there is a unique vocabulary. Much of this vocabulary is not (or should not be) specific to any type of legal document. For instance, the notion of in a court filing must not, and probably should not, be different than the notion of in a contract or a treaty. Furthermore, certain non-legal elements, such as and
, can be expected to be found in all types of legal documents. In the Legal XML Workgroup we have been referring to both legal and non-legal, non-structural elements as "semantic" elements (whether or not this is "correct" use of "semantic", this is what we have been calling it). "Semantic" elements are the "meat" on the various "skeletons." BRAINS: Although we have not reached consensus, there are some in the Legal XML Workgroups (myself included) who see the need for "header" information for legal documents. Header information might include various types of information, including but not limited to (1) routing or workflow information (2) information about authorship, revision history, etc. and (3) summary or bibliographic information. SKIN: Legal documents must be signed and/or kept confidential. There is a need, therefore, for digital signatures and encryption (sealed digital envelope). The digital signature and/or digital envelope is the "skin" that holds the "skeleton", "meat" and "brains" together. The Legal XML Workgroup would like to leverage on the work of a larger community of "skin" developers. We would also like to contribute to such work. It is my position that an XML-Digital Signature specification can be and should be developed that is generic enough so that XML documents (or BLOBS) from any industry can be digitally signed and/or encrypted. The following is a list of desired requirements: 1. Generic (usable by any industry) 2. Non-Proprietary 3. Digital Signature and Digital Envelope (encryption) 4. Signature of and Envelope around both XML and BLOBs (MIME types) 5. For XML Documents, Co-Signature of Entire Document, Request Authorization: Signature of (Signature + Additional Content), Endorsements 6. Multiple Document Signing (regardless of whether documents are XML, BLOB, or combination of both) 7. Time Stamps 8. WYSIWYG-capable Signatures and Envelopes By WYSIWYG-capable Signatures and Envelopes I am referring to what appears to be one of the most important issues/obstacles (assuming I understand correctly) -- XML Canonicalization Requirements or the lack thereof -- the ability to digitally sign XML elements/trees (as opposed to the byte-stream) while assuring that what has been signed accurately represents all of the information the signer viewed through the GUI. Here is a legal perspective: When a lawyer introduces and signed paper document in court claiming that it is attributable to a purported maker, the lawyer, as a threshold matter, must "authenticate" the document. For instance, under Federal Rules of Evidence 901(a), "The requirement of authentication or identification as a condition precedent to admissibility [of a signed document, among other things] is satisfied by evidence sufficient to support a finding that the matter in question is what its proponent claims." What this means, basically, is that the lawyer "lays a foundation" -- says some magic words -- that gives everyone in the courtroom a warm fuzzy feeling that the evidence is what he says it is. This is a very low threshold. At the culmination of laying a foundation, the lawyer generally shows the document to the witness who states in open court either "Yes, this is the unaltered document and this is my genuine signature" or "No, this document has been altered and/or it is not my signature." In the former case, there is no problem, the document is admitted and the case goes on. In the latter case, where the witness denies the document or the signature, the proponent of the document has the burden of proving that the document and the signature are unaltered and authentic. This requires much more proof and takes time and money. Why does it matter? Imagine the difficulty that a lawyer will have if the witness does not recognize the document at a glance -- that is, the content within XML tags is unaltered, the digital signature is valid, but a different style sheet is used that makes the document look different -- big problem. What happens if it comes to light during a trial that a document author inserted comments between XML tags, but that those comments were omitted during the signing process. If the comments are relevant (possibly even if they are not, since they are absent and/or reputable), then there is a big problem. Or, alternatively, what happens if it comes to light that the application (not the author) inserted and signed comments and or "header" information of which the author was unaware. Now we have additional information that could cause problems. Please understand, I cannot say in any of the above cases that the evidence is completely worthless (the law has few, if any, binary answers), because it probably won’t be deemed completely worthless. However, little peculiarities in how the technology works will give lawyers the ability to argue for or against the credibility of the evidence. If it is perceived by users that a particular technology is subject to legal arguments against it, the technology will not be used. As a general matter, it is safe to say that what a document author/signer writes and/or sees when he/she signs is what should be signed because what is seen/read is that for which the person will be held legally accountable. The technology should not produce inconsistent results based on random applications -- whether this can/should be prevented by technology or by policy, I’m not yet sure, but I believe strongly that WYSIWYG is an important requirement. Some general principles: If an author writes a comment, then the comment should be signed. If a graphic or other object (spreadsheet, chart) is included (seen) in a document, it should be signed. Dynamic content should be signed. If a link is included in a document, then the text of the link should be signed. The default should be that information on the other side of the link should not be followed and signed, unless the author chooses to incorporate the other information. This is not a perfect rule (because the information on the other side may be important and there is no guarantee that the information will remain available, but it does take care of the www.yahoo.com problem and it gives the author/signer control of what he/she signs ( i.e., to what he/she is legally bound.) This one won’t be popular, but style sheets should be signed. I’m not sure about general entities. I need to see more examples. Again, I apologize for the tardiness of this reply. Winchel "Todd" Vincent III Attorney and Technical Researcher Georgia State University The Center for Digital Commerce and College of Law Phone: (404) 651-4297 Fax: (404) 651-2092 Email: winchel@mindspring.com Web: http://gsulaw.gsu.edu/gsuecp/