Court rules, funding, legislation, and management vary from state to state. Some states have consolidated their court systems, while many have not. Even the degree of consolidation varies from state to state. Whether courts are consolidated or not, each state needs to maintain certain controls within the law for governing standards, certification, licensing, and management of electronic filing implementations. A common practice that state supreme courts are using to help lower courts test and pilot electronic filing technology is to create a court ruling that gives the court leniency for participants against current court rules. This makes it possible to test, identify, and make proposals to change existing rules to facilitate the electronic filing process.

As states advance in the development of court rulings that support electronic filing, more and more issues are exposed. In early filing projects, the scope of efiling projects was usually limited to a specific case, case type, or a specific court. As the scope of the project enlarges from a single case type or court, to a statewide perspective that deals with all types of cases, the complexity increases. These issues require a state to establish new controls and rules that affect the entire state, yet at the same time lower courts need latitude to adjust state rules to meet the needs of lower court rulings.

The controls and rules a state will adopt should include a state certification process to govern the interaction between efiling vendors that may be installed in various courts within a state. The basis of this position is to protect the interoperability of the filing process among courts within a state. Because attorneys frequently file in multiple courts within a state, interoperability must exist among courts or attorneys will become discouraged. Building vendor-unique processes to interact with each court will quickly break down the interest of attorneys to participate. The success of an efiling project will reflect in the states’ ability to define and implement the proper rules and controls.

Not all aspects of the efiling process need to be controlled at the state level. For example, some courts may provide software that supports the entire efiling process while others may rely on third party service providers to support features of the system. The state does not need to control which configuration a court supports but it is important that they control the standards that each provider must conform to. There may be some issues where the state makes recommendations but not mandates. Some issues dramatically affect the outcome of the state, while others do not.

This document will discuss many of the complex issues that affect efiling. The purpose of discussing these issues is to expose to each government agency issues that they need understand, and to the issues and take steps to address them. Tybera’s eFlex helps address these issues by simplifying the court’s burden and centralizing the solution with an easy to manage product. eFlex takes into account both the filer as well as the court so that both sides are willing participants.

One of the more unclear issues of efiling is user identification, how to control the identification process, and what information should be included in an efiling sent to a court so that the court clearly understands who submitted, approved, or signed the filing.

This is a concept that is unclear in the recommended standard adopted by COSA and NACM. The lack of clarity is due to the confusion between unique user identifications and usernames/passwords that are used to access software or a service provider’s applications to create and transmit a submission to the court.

For clarity this paper proposes two terms and definitions, they are:

1. Electronic User Identification (eID); An eID is an identification that verifies that a person is who they say they are electronically.
2. User Account Access (UA); a UA is a process that identifies how a user accesses an application electronically. This frequently requires the assignment of a username and password to access the server where the application is installed.

State agencies are already in the business of issuing user identifications. Driver licenses and state identification cards are examples of photo IDs that function in the paper world. These user IDs are frequently used to verify a persons identity.

The concept of a username and password to access a network is nothing new. Most every network or application service requires a username and password for the user to gain access and utilize applications such as email.

The need to create a state policy for eIDs in addition to photo IDs may be new. Those states that have passed digital signature laws where the certificate authorities are licensed by the state have actually paved the way for eIDs. Generally, the certificate authority must create policies that determine the process where by a user can verify their identity and then receive an ID, or a digital certificate. In fact, the digital certificate contains the essence of an eID. These specific types of IDs have struggled to be accepted by the general population because of the difficulties users face with the entire process of acquiring, managing, and using digital signatures, but the concepts are relevant.

State issued user IDs play a role in our daily lives, and moving to the concept of eIDs is not unreasonable. Many situations rely on these user IDs, from cashing a check to checking in at the airport. Just as photo IDs are utilized in the paper world, eIDs will be used in the electronic world. This raises the following questions:

• Does the state need to establish methods or procedures for users to acquire eIDs?
• Should all courts within a state utilize a common eID system?
• Should the State Administrative Office of the Courts, where applicable, be the eID authority?
• Can the state outsource this service?
• Should a third party agency be responsible for eIDs?
• Should an eID be renewable? Unlike printed user ID, eIDs can be breached and thus processes to revoke and renew eIDs need to be implemented.

eIDs are not the same as user account access. User account access is a control process that frequently includes a username and password. This access control is for a specific service but does not fulfill the role of verifying that a user is who they say they are. To demonstrate the distinction between an eID and UA, consider the process of creating a bank account. In order to create a bank account a state issued Photo ID is normally required. From this verification process an account can be established. The bank then creates a new account with your photo ID information, assigns a unique ID or account number specific to the bank. If a user then wants to access information over the web on their bank account, the bank will create a password to access the account. The user can change the password at the bank, but the account name and password have limited association with the state photo ID. Two identification processes participate in order to complete the business relationship; the user ID issued by the state and the account ID with password issued by the bank.

Transferring this process from the paper world to the electronic filing world should follow the same behavior. States should govern the issuance of eIDs, but leave the UAs, or username and password to the organization that is providing services to end users. There must be coordination between the organization issuing eIDs and the service providers that generate accounts with usernames and passwords.

The coordination exists when a submission is created. The UA allows the user to create a submission while the eID is associated with the user account that created the submission. The eID is embedded in the submission and is then transmitted to the courts but the UA (username and password) is not embedded into the submission. The court that receives the electronic submission must be able to check the eID status with the state authority. Some of the questions this issue raises are:

• How does the state issue the electronic IDs?
• If the eID is compromised how can users renew their ID?
• If the UA is compromised does that mean the eID is compromised?
• How do service providers interact with the state agency issuing the eIDs and associate the UA with the eID?

Transferring the signature process from the paper world to the electronic world has been a difficult area to promote. Most courts have begun to simply avoid the issue of signatures as a part of electronic filing. This avoidance has come because of the uncertainties and lack of education on the part of end users about the technologies that are used to create digital signatures.

Digital signatures supported by Public Key Infrastructures (PKI) have proven to be the most reliable method of combining the relationship of eIDs, documents, and the actual signature. Unlike imaged signatures, (which are an electronic representation of ink signatures), digital signatures have no meaning when viewed by the human eye. An imaged signature looks like a signature made with ink and paper and the human eye understands its intent. Digital signatures are series of electronic digits that can be programmatically processed. Digital signatures support non-repudiation better than any other method of electronically signing information. They are the only electronic signature technique that provides methods to programmatically compare and verify the digital signature against a specific document and electronically validate the identity of the person that created the signature.

Still many industries, including courts, are moving away from the use of digital signatures because they do not want to burden their end users with the challenges these types of signatures present. Some of the challenges include:

• Users don’t want to purchase certificates required to create digital signatures,
• Many states do not have a license policy for certificate authorities that issue certificates,
• Users do not understand how they work,
• Using a certificate usually is dependent on the use of a specific computer because of the way certificates are stored and managed,
• When users change computers due to upgrade or new purchase they do not understand how to transfer the certificates to the new machine and destroy them off the old machine,
• A certificate authority’s policies are restrictive and easily broken, or users do not understand them.

Certificates are normally stored in the web browser on a specific computer. When the certificate is associated with a specific machine a burden is created for the user in signing information. Generally, an application that requires a signature must first download software to sign the data and then package the information in an appropriate format before it can be processed. For example, how does one receive the digital signature in a LegalXML envelope? The application must download software to the specific machine the filer is working on to create a digital signature and the certificate must already be on that machine.

The requirement to download software before you can participate in an electronic filing process goes against the desires of most efiling requirements. Most efiling systems are pushing to avoid forcing a user to install software on their computer in order to use the efiling system. For an efiling system to be easy to use it must eliminate or minimize what the user is required to install. Installing anything means the user is bound to a specific machine to get work done.

Many courts are moving towards the concept that the UA procedure is enough to imply that an electronic "approval" instead of a signature has been applied to any submission created with that account. Simply assuming that the UA process is adequate to insure that someone signed or approved a document leaves limited and vulnerable electronic evidence. The ability to verify that someone did actually sign something electronically ends up being stored in a log file. Log files are vulnerable and can be easily tampered with. In addition, the actual log files created for the submission may not be owned or stored at the courts. All of this leads to difficulties proving that someone did something when. When all that exists at the court, in terms of electronic evidence, is either the LegalXML envelope, or even less valuable, the documents that were extracted out of the envelop because the envelope was discarded.

Signature policies that vary from one court to another will dramatically affect the interoperability of a statewide system. More important to this issue is the electronic evidence that exists. Following is a list of questions to consider regarding this matter:

• Is a log file adequate information to support the premise that a user approved/signed a submission?
• Can submissions be tampered with after they have been sent?
• Is there any reason to protect the signature information as electronic evidence or secure the entire process in order to prove that someone actually did something?
• Should the electronic filing system trust that the software that created the submission authenticated the individual before the end user was allowed to submit the filing?

The state should create a statewide policy on signatures. This issue will affect the issues of document integrity and electronic evidence protection and storage. The signature policies will also affect the Electronic User Identification policy.

Many documents that are submitted to the courts require notary signatures. Moving the notary process from the paper world to the electronic world only complicates signature problems further. Some states have suggested that notary signatures are no longer necessary for documents submitted to the courts. They suggest that there have been no court cases in the last 50 years that have challenged a signature on a document submitted to a court. Perhaps this is because the notarization process has eliminated any problems with signatures, or the issue of checking signatures has become outdated.

One state has proposed a change in court rules, which will substitute notary signatures on documents filed to the courts with documents that are digitally signed. They have adopted this change because digital signatures include a process of verifying that the person is who they say they are, and digital signatures provide a means to check the status of the certificate used to create the signature. This process, in a sense, uses a third party to verify a signature, which is one of the aspects of the notary process. In addition, the certificate authority that issued the certificate verified that the person was who they claimed to be before the signature was applied. This is another function of the notary.

This change in rule demonstrates the inter-relationship between an eID embedded in a submission, signature policies, and how they work together to replace the notary function.

Each state needs to review the paper documents being filed to the court and ask if the notary signatures on those documents are required, if digital signatures can replace them, or if the requirement can be eliminated. This issue is affected by the Digital Signature policy.

When information is exchanged using a public network such as the Internet, the integrity of the information being exchanged can be called into question. Because of this, each state should establish a policy that software providers must use to ensure data integrity.

Data integrity can be addressed using a couple of methods. The first method is to protect the data from being changed during transmission. SSL and SHTTP are standard Internet protocols for communication to a web server in protected mode. Referencing a document from the IBM developerWorks library on security written by Doug Tidwell, Cyber Evangelist, developerWorks XML team
April 2000, he says:

1. Confidentiality -- No one else can access or copy the data,
2. Integrity -- The data isn't altered as it goes from the sender to the receiver,
3. Authentication -- The document actually came from the purported sender,
4. Non-repudiation -- The sender of the data cannot deny that they sent it, and they cannot deny the contents of the data,

The same is true for SHTTP. The first three features exist during the transmission process. After the transmission the data is then unprotected and the confidentiality, integrity, and authentication information is gone. Modifying this data may require that someone have access to the server where the data is stored. It is anticipated that internal users should be trustworthy and not tamper with the data, however it is not guaranteed. Many breaches of security and data integrity come from within an organization. In addition, the ability of hackers to gain access to the data is then dependent on the quality of the network security. If the data is routed through multiple servers to reach its final destination, the chance of it being tampered with rises as it moves from server to server.

The alternative method of protecting data is by adding the concepts of non-repudiation. This can be accomplished by including information in the submission that is part of the data and thus remains in tact after the transmission process. This information stored in the submission can be used to test the integrity of the data at any time after the submission has been stored and routed to other servers. This does not eliminate the desire to use SSL or SHTTP for communication, but by embedding information in the submission it is now possible to test the integrity of the data at any point in time after the transmission. Using digital evidence locking techniques, proposed by Tybera to the LegalXML Technical Committee in April 2003, will protect the integrity of the data and provide nonrepudiable evidence that a specific server sent the submission.

As mentioned earlier in the section on signatures, the concept of storing what was received by a state should be considered electronic evidence. This includes more than just documents. It includes who signed the documents, exactly what documents were included in the submission, and what was not included in the submission.

Each state needs to consider the issues surrounding the value of data integrity and storing of electronic evidence and how to protect and secure the data can be used later if needed.

As mentioned above, SSL and SHTTP are Internet protocols that provide authentication during the transmission process that the information being transmitted comes from a purported server. But this does not mean that the purported server was authorized to send the submission. Submissions could come from sources that are not authorized. Unauthorized sources could submit valid LegalXML envelopes with user information and data that appears to be valid. These submissions must be filtered out and discarded. Not only is it necessary to validate that the submission came from the purported server, but also that the purported server has been either certified, licensed, or in some way recognized or authorized to send submissions.

This level of authentication does not authenticate the filer. The source server that issues UAs authenticates the filer and creates the LegalXML envelope (the job of an EFSP). The authentication process we are discussing in this section is the authentication of a server (controlled by the EFSP). The EFSP server that is transmitting the submission. This is the server that needs to be authenticated.

Authenticating that the server sending the submission is who they claim to be is the process of SSL or SHTTP. The state must provide methods to authenticate which servers are authorized to submit efilings.

Other sources that fit this category may be law firms that have installed their own software and bypass an EFSP.

This authentication is in addition to securing the line during the transmission, and the EFSP authenticating users through their account access procedures. Verifying that the source of the transmission is indeed authorized to submit filings will likely require an authorization or certification policy that is managed by a state authority. Once the certification or licensing policy and process is complete, the state is then responsible for providing software to communicate the EFMs which servers are authentic sources. It should also be noted that EFMs might also need to be certified by a state agency to ensure that they conform to state requirements.

By reviewing the process of authentication we see that there are several authentication steps that take place. These steps follow an order that results in a "checks and balances" approach.

Authenticating the source submitting the filing can be approached in multiple ways. One method of authentication is firewall software and published certification lists. If the EFSP approval process for an EFM is manually done, and the number of service providers is limited, then an EFM can use a to authenticate the EFSPs and manually maintain the list of authenticated sources. In effect, the authentication of the EFSP to the EFM is configured in the firewall and is based on a list published by the State. One weakness is the update and maintenance process. If an EFSP looses their status the EFM manager needs to constantly review the published State listing. If the EFSP changes their IP address this requires the State to make changes and the EFM to make changes manually.

We anticipate many vendors will add EFSP technology to their products. This will dramatically increase the number of EFSPs available for adoption by attorneys and state agencies. Managing multiple EFSPs with a firewall and published listings is not scalable and will be a security risk. Tybera’s patent pending distributed authentication model and software makes it easy to manage and control the authentication of sources, status, and published listings. It is simple to implement, and easy to manage.

Data encryption refers to the protection of information embedded in a submission from unauthorized viewers. Submissions can be held in either temporary or long term storage. It is unclear who can access the servers where this submission data is stored. If the information is sensitive and needs to be sealed, there must be methods of encrypting the data so that those with access to servers that contain sealed data cannot view it. Only those with proper authorization should be able to read sealed data.

This concept of data encryption is not addressed in the current ECF standard, nor is it part of the LegalXML envelope. But the concept was introduced to the LegalXML Technical Committee in December of 2002.

The data is encrypted and stored in the envelope. The data is extracted from the envelope for users that act upon the information. Once the sealed data is unencrypted it is the responsibility of the user that accessed the data to protect it. However, Tybera feels that storing the envelope is proper maintenance of electronic evidence and therefor the envelope should not be discarded

Each state needs to recognize that integrated justice is or will be a critical issue. In a non-consolidated state, the likelihood of each court installing software for efiling that does not interoperate with other state agencies will hinder integrated justice. This does not mean that the software at each court will not allow for integration. But the overall effect of every court having a slightly different integration process will create a burden for state agencies that do want to communicate with the courts. This burden would be in the form of trying to integrate to multiple state/county courts where each may be slightly unique. A single source of integration for all state agencies is necessary to support the communication to all court EFM systems. Each EFM then needs to accept information from the single source that state agencies integrate with.

As with the eID issue, the concepts of notification should be managed at a state level rather than at the local level. Notification should be interwoven into the eID process as well as the relationships with UA accounts. Each state should consider the integration challenges and extra costs that will exist if they do not integrate these features together.

There are several events that must be recorded. This record includes the time each event occurs. The time a court receives a document is a critical issue. Several efiling projects have failed because the filers did not receive adequate notice if their filing was even received. If a users files electronically and does not receive a assurance from the court, before the filing time expires, that it was received (a digital receipt), they will assume it was not and abandon the electronic format and revert back to paper with runners.

There are several timing events that can be tracked. Some of the events occur in the EFSP software while others occur at the EFM. The EFSP software can record and store the time at which the user logged in and created the submission. It can also record when the submission was transmitted to the courts.

The EFM can record when the court received the transmission. If the EFSP were to include these recorded times in with the submission then the EFM would have that information as well.

In addition to the time at which the courts receive the documents, the time the documents were docketed, processed, accepted or rejected by a clerk or judge can be recorded.

Some courts have extended to EFSPs the authority to receive documents on behalf of the courts, which makes them an agent of the court. This raises a serious question of who should be allowed to be an agent of the court. When you consider that law firms will soon be able to purchase EFSP software, are they to be considered agents of the court they are filing to? We don’t think so! When a law firm installs their own EFSP software the court should not allow their timing events to be recorded as agents of the court.

Each state should create policies of what timing events are critical and what rules will govern them. For example, will the time the submission is received by the court be the official docket time even though it might take several days for the information to be posted to the court’s case management system?

Tybera provides a solution that addresses all of these complex issues by making it possible for a court AOC to establish controls and testing facilities for state certification required to manage efiling. By utilizing the Tybera eFlex software, state agencies are able to choose the level of control they wish to have over electronic identification and user access. These controls include:

• Software for Electronic User Identifications (eID),

• Support for the method of issuing and managing electronic user IDs,
• Issue, revoke, renew, status verification,
• Support for integration of eID with EFSP vendors,
• Teach and certify how to complete the eID process,
• Teach and certify how to load the eID,
• Teach and certify how to embed the eID in each submission,
• Support the eID status check from EFMs,

• Support for digital signature implementation,
• Using the Tybera simplified eID controls,
• Third party Certificate Authorities,
• Teach and certify how to use the eID in a submission to sign data,
• Integrate with other EFSPs for eID, status reports, notifications, and single source integration,
• Support for document integrity,
• Teach and certify EFSPs on how to implement the digital lock to secure submissions,
• Support for data encryption of sealed documents,
• Establish a single source of public key storage for all EFMs and EFSPs,
• Teach and certify EFSP how to encrypt sealed data using key pair swapping,
• Support communication authentication,
• Support court rules for timing events,
• Provide single source integration that will communicate to all EFMs,
• Provide the ability for courts to pilot electronic filing.

For more information on electronic identification and user authentication, or how to initiate an efiling pilot program in your court, contact:

Dallas Powell or

Norm Anderson

801.226.2746

Copyright Tybera Development Group, Inc. 2001-2003