[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [legalxml-courtfiling] EFiling Process Models Subcommittee
Also..... EMails are perceived to be secure by many, but in reality, email can be read depending on whose email server it may be being passed through. Trusting EFilings with confidential data to non-encrypted email should be avoided. Allen Jensen Orange County Superior Court Internet Development / EFiling 949.472.6946 >>> Dallas Powell <dpowell@tybera.com> 12/31/02 03:14PM >>> Here are some thoughts that were generated as I read several threads such as the DOS comments.... A denial of service attack can take place on an e-mail address just as it can take place on any IP address. In fact the danger of using an e-mail address for an e-filing method is that the email server is frequently a central component of other court business and an attack on a central email server could hurt other areas of the court. Also, the e-mail system generally does not have a sophisticated design that allows the e-filing system to deal with hundreds of e-filings being received with 100 Meg files attached in a hours time frame. Just think, 10 filings a minute with 100 Meg files attachments, in one hour, means 600 filings with 60 Gig of disk space consumed. That does not even look like an attack from an e-mail or an IP address perspective but could bring a system to a halt. An e-filing system needs to be isolated from other businesses of the court, either as a web server or as an isolated e-mail server. The only way you can stop an attack is to not tell anyone about the IP address, but that makes no sense. The best way to defend against an attack is to put into place a security model for the EFM which quickly filters the bogus filings from the real filings. The philosophy we support in our implementation is to prepare for the attack, and stop the unwanted postings as fast as possible... the first thing. The deeper you allow bogus filings to enter into your e-filing system the more damage you incur. We support the idea that security is the most critical aspect of an EFM. Just think, if an attacker wanted to be smart he would create valid CourtFiling 1.1 packets, possibly vary the information, and send them. If the EFM only checked to see if the filing validated against a DTD then the bogus filing will pass level one of security checking. Now suppose that you wanted to use the attorney's bar number as a second check. Well, since those bar numbers are public information in many states, it will not be a problem for a hacker to insert valid information in that field. And what about credit card information... is that a valid security check,,, no! There is nothing in the current DTD that supports any form of authenticating the submission. Can you imagine having thousands of cases submitted each day that passed the DTD validation, Bar No., and credit card check. How soon would it take for a Court to shut down when thousands of cases are being entered into a CMS each day? And there is no way a court clerk can afford to research out each filing to see if the information is valid because the information in the filing represents valid people, it just came from the wrong source. The Court would begin to shut down before the web server even realizes there is an attack going on. A new concept in attack, hide what you are doing so that the court you are attacking cannot tell you are attacking. Now to increase the complexity of the problem, we want an open system so that anyone can create software to submit filings. That is the concept between the EFSP and the EFM. If you only allow one or two EFSP installations to submit filings then you could use a firewall or a VPN for securing who the submissions come from. In this case a court would probably create a contract relationship between a few EFSP installations, and each EFSP would be held liable to insure that all users of their system were authentic and that the EFSP was responsible for any bogus filings. But then that would not be a very open system. To me that seems a bit closed! More like very closed, and it forces all attorneys to pay a few EFSP installations a ransom if they want to file electronically to a court. (This is a great business model for an EFSP but not very good for an attorney or other filers.) Personally I don't think that this is what an open standard is about. To me, the concept of an Open Standard, makes it possible for numerous EFSP installations, hundreds or thousands to exist. This means firewalls and VPNs are unrealistic methods of identifying unauthorized submissions. Firewalls are still needed to protect internal processes and network security from externally exposed processes, but they do not readily support the authentication of submissions that may come from hundreds or thousands of installations, especially where there is continuous address changes. It is my impression that the Open Source Code projects have either adopted the concept of only a few EFSP installations and use an firewall for security, or they have not addressed the security risks. We struggled in our implementation and design with this very issue. For Utah, in addition to the EFSP service installed at the courts where all attorneys to use the service at no cost, Utah also mandated that any attorney, or other organization such as the attorney general, Dept. of Corrections, Human Services, etc, that wants to write software to communicate to the EFM can do so. ---(Note of historical experience from Utah: We have found that for high volume filers the idea of installing software at their site allows them to automate their internal processes. This is very attractive to them, and we anticipate that more filings will come from this type of installation than through an attorney logging into an EFSP on the web. As you begin to evaluate who files and what they file, you will find that frequently a handful of attorneys file 80% of a given type of filing. For example, one attorney can represent a collection agency and initiate 300 to 700 cases per month. In Utah we identified about 10 attorneys that behave this way. When you consider the additional default judgements, and post judgement remedies these 10 attorneys file, that accounts on an average of ... 500 cases x 10 attorneys x 12 months + 1000 follow-up filings x 10 attorneys x 12 months equals 180,000 unique filings per year from 10 attorneys just for one type of civil case. If the number of filings is significant it is worth the money for an external organization to implement software to automate their processes. Utah has implemented more than 5 unique electronic filing solutions. One solution allowed the Office of Recovery Services to file documents electronically to them, but it did not automate the CMS or DMS. Another solution was unique to the Tax Commission. Another unique solution was totally web based, but they found this was too difficult to scale, and complex cases were even more difficult to support. Another unique solution was built for one attorney who filed 500 filings per month for a large hospital chain. He automated his process and the courts automated their process of initiating their CMS. It used e-mail, and CourtFiling 1.0. This solution updated the CMS but not the DMS. They found that they had no security model, and the system was not something that other attorneys or organizations could readily adopt. In addition, this last system for the attorney required follow-up paper work and a special payment process. )----- So, how do you publish a security model to the open public that communicates to the EFM, and at the same time, when each party writes code to meet the security model it does not jeopardized in any way the ability of the EFM to recognize and authenticated source or submission from unauthenticated source or submissions? That is exactly what we had to deal with. Now introduce the issues of interoperability... If you look at the levels of interoperability we originally proposed, they go from the easiest to the most difficult. Remember there were 5 proposed levels, 1) Basic validation 2) Communication layer ( protocol and hand shaking) 3) Required elements for case initiation and case updates 4) Required elements for filing fees 5) Security Model In the Las Vegas meeting rather than just adopting the interoperability document that was submitted we reviewed it and before we finished with level 1 and 2 (which were collapsed together in the document) we found that there were many issues that we felt needed more attention. In light of our new EFiling Process Model Subcommittee we could see that we need to begin to define models and processes before interoperability could be defined for each process. So, to wrap up, it is my feeling that we often talk in general terms about processes and interoperability and skim over the details of how it might actually function in a specific business model, or under a given interoperability level. As we mature the EFiling Process Models and the Layered Interoperability working groups we will develop better methods to discuss with more clarity how a process interacts with other processes. We have worked too long in general terms and must begin to create a structure that helps us in our discussions. Define business models, define processes, and describe how they work within each business model and how they effect each level of interoperability. As I began to approach the description for the statement of work for the Layered Interoperability subcommittee, I anticipate there are two parts, one is a living document which will be used to collect definitions of interoperability based on various business models, and then a specific document that creates a statement of interoperability for CourtFiling 1.1. In Las Vegas we began to recognize that there was not sufficient information in the current concepts of LegalXML architecture to define interoperability. I solicit any input on the topic of interoperability and promote Dwight's request for participants to describe various business models and process definitions. Then as we begin to discuss issues we can point to specific models, and levels of interoperability and make better decisions and standards. Dallas ----- Original Message ----- From: "John McClure" <jmcclure@hypergrove.com> To: <legalxml-courtfiling@lists.oasis-open.org> Sent: Friday, December 27, 2002 12:58 PM Subject: RE: [legalxml-courtfiling] EFiling Process Models Subcommittee > Allen, > A few thoughts. > > Although I am not an EF maven, your question of pushing and pulling is generic. > I think that a critically important function of the architecture must include > minimization of DOS attacks (Denial of Service) on a judicial system. Pushing > filings to an EFM opens the door to DOS attacks. I'd suggest a hybrid approach, > in which a filing REQUEST is pushed to the EFM, and the EFM then pulls the > filing into its repository from the URI specified in the filing request. I don't > know whether this represents a refinement or just a restatement of the current > LegalXML architecture, but I'm sure that I would agree that eliminating EFM for > a direct EFSP to CMS/DMS data flow is not a useful simplification of the > architecture. In other words, I see the primary function of the EFM to be > fielding the filing requests, checking its technical parameters and payment/case > information, and then performing the pull. An email is then sent to the filer as > confirmation of the pull completing successfully, or of an error occurring. An > important related business issue I think concerns whether filing deadlines would > be relative to receipt of the filing request, rather than to the pull performed > by the EFM. > > I do support John's initiative to orient EFM implementations to be formal web > services, using SOAP as (one of) its underlying exchange protocols. At the same > time, I think it's important also to include an SMTP processor in the EFM for > email-based filings -- the EFM's job in this case would be to convert email with > its attached filing into a web service request. This would allow a court to > advertise both filing methods, catering to the varying levels of technical > sophistication of filers. Email based filings is a good strategy against someone > wanting to initiate a DOS attack against a court system but, then again, the > business rules for emailed filings may need to be similarly addressed as for the > client/server model discussed above. IMO, an email-based filing process should > have priority over a web service implementation, occupying our attention until > WSDL becomes fully mature. > > With respect to the interface between the EFM and the CMS, another cycle of the > same loosely-coupled email based architecture or more tightly coupled web > service could occur, one in which the CMS is notified of the availability of a > filing to be processed by the CMS. The CMS then pulls that filing from the EFM > repository, with an email notification to the EFM when the filing has been > pulled by the CMS. The notification includes not only the URI for the filing > itself, but also the URI for the Court Policy document that rules the transfer > process. The recipient CMS can access both documents using standard XSL. > > In no event should an API be used to (too tightly) link these systems. We don't > need to standardize on CORBA or a custom HTTP negotiating mechanism given > industry consensus around WSDL. An API to a court policy document I am concerned > jeopardizes adoption of a standard for the XML encoding of that document. Ditto > for filing APIs. > > John McClure > > >-----Original Message----- > >From: Allen Jensen [mailto:ajensen@occourts.org] > >Sent: Friday, December 27, 2002 8:18 AM > >To: drdaniels@bearingpoint.net; Tom.Clarke@courts.wa.gov; > >jmessing@law-on-line.com; Donald.Bergeron@lexisnexis.com; > >legalxml-courtfiling@lists.oasis-open.org > >Subject: RE: [legalxml-courtfiling] EFiling Process Models Subcommittee > > > > > >I'm still having trouble with one generic EFM/OXCI PUSHing the > >data/images into all the various CMS/DMSs? Since every CMS/DMS > >implementation is different, wouldn't it be more likely to have the > >CMS/DMSs PULL the data from EFM? > > > > > > > >Allen Jensen > >Orange County Superior Court > >Internet Development / EFiling > >949.472.6946 > > > > > > > >>>> John Messing <jmessing@law-on-line.com> 12/27/02 08:13AM >>> > >Then in the same spirit I would like to pose a question to the > >consortium whether OXCI can do anything more or better than XSLT and > >ordinary web services such asp.net together. If not, and the latter are > >standardarized and freely available, why not consider using them > >instead? > > > >---------- Original Message ---------------------------------- > >From: Tom.Clarke@courts.wa.gov > >Date: Fri, 27 Dec 2002 08:02:21 -0800 > > > >>Well, I hesitate to speak for the OXCI consortium when some of these > >>architectural decisions have not been finalized by either the OXCI > >>Consortium or Legal XML. OXCI is intended to be an EFM reference > >>implementation. As such, it does need API's for interacting with an > >EFSP, > >>Court Policy, Court CDC, a CMS and a DMS. > >> > >>It also assumes the existence of a CMS/DMS-unique Adapter that stands > >>between the EFM and the CMS/DMS. The Adapter handles some of the > >>translation duties, since the OXCI group suspects that to do otherwise > >would > >>put an unrealistic burden on the EFM, Court Policy and Court CDC. > >Some > >>vendors suggested that might be the case during discussion of the last > >Court > >>Policy version. > >> > >>I would like to refer any additional questions about OXCI to Greg > >Arnold, > >>who leads the OXCI Consortium. > >> > >>-----Original Message----- > >>From: John Messing [mailto:jmessing@comcast.net] > >>Sent: Thursday, December 26, 2002 5:40 PM > >>To: Tom.Clarke@courts.wa.gov; Bergeron, Donald L. (LNG); John > >Messing; > >>Daniels, Dwight (BearingPoint); > >legalxml-courtfiling@lists.oasis-open.org > >>Subject: Re: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >> > >>I understood that OXCI was a way of parsing the xml and sending it to > >the > >>CMS-API for translation into methods and properties that the legacy > >CMS > >>systems could use. Are you saying that OXCI does otherwise? > >> > >>----- Original Message ----- > >>From: <Tom.Clarke@courts.wa.gov> > >>To: <Donald.Bergeron@lexisnexis.com>; <jmessing@law-on-line.com>; > >><drdaniels@bearingpoint.net>; > ><legalxml-courtfiling@lists.oasis-open.org> > >>Sent: Monday, December 23, 2002 10:48 AM > >>Subject: RE: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >> > >> > >>> I just want to respond to John's comment about OXCI. OXCI is > >looking > >>> closely at using a web services approach to all API's and reusing > >>> appropriate parts of Version 3.0 of the Justice XML Data Dictionary > >>schema. > >>> In any case, it is likely that schema will be used instead of DTD's > >and > >>the > >>> standard web services messaging protocol (either SOAP 1.2 or ebXML > >>Messaging > >>> 2.0) will be used. The California 2GEFS project is the one not > >planning > >>to > >>> use web services. > >>> > >>> -----Original Message----- > >>> From: Bergeron, Donald L. (LNG-DAY) > >>[mailto:Donald.Bergeron@lexisnexis.com] > >>> Sent: Monday, December 23, 2002 6:35 AM > >>> To: 'John Messing'; Bergeron, Donald L. (LNG-DAY); 'Daniels, Dwight > >>> (BearingPoint)'; CourtFiling List (E-mail) > >>> Subject: RE: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >>> > >>> These are possible effects of effort described. This will occur when > >we > >>look > >>> at the functions supported by these technologies and how they apply > >to a > >>> better defined set of Models required by the community. > >>> > >>> > >>> Regards, > >>> > >>> Don > >>> > >>> Donald L. Bergeron > >>> Data & Systems Architect > >>> donald.bergeron@lexisnexis.com > >>> > >>> 937-865-1276 O > >>> 937-748-2775 H > >>> 937-672-7781 M > >>> > >>> > >>> -----Original Message----- > >>> From: John Messing [mailto:jmessing@comcast.net] > >>> Sent: Monday, December 23, 2002 9:01 AM > >>> To: Bergeron, Donald L. (LNG-DAY); 'Daniels, Dwight > >(BearingPoint)'; > >>> CourtFiling List (E-mail); EFiling Process List (E-mail) > >>> Cc: Bergeron, Donald L. (LNG-DAY) > >>> Subject: Re: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >>> > >>> > >>> I think we need to look at > >>> > >>> 1. web services as a replacement for CMS-API and OXCI, which are > >now > >>> outdated technologies in my opinion, and focus on exposing the > >methods of > >>> the case management systems to the web directly through XML web > >services; > >>> and > >>> > >>> 2. look to Schemas and RDF solutions being developed in parallel so > >as to > >>> stay abreast of the technological curve. > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Bergeron, Donald L. (LNG-DAY)" > ><Donald.Bergeron@lexisnexis.com> > >>> To: "'Daniels, Dwight (BearingPoint)'" > ><drdaniels@bearingpoint.net>; > >>> "CourtFiling List (E-mail)" > ><legalxml-courtfiling@lists.oasis-open.org>; > >>> "EFiling Process List (E-mail)" > >>> <legalxml-courtfiling-processmodels@lists.oasis-open.org> > >>> Cc: "Bergeron, Donald L. (LNG-DAY)" > ><Donald.Bergeron@lexisnexis.com> > >>> Sent: Monday, December 23, 2002 6:51 AM > >>> Subject: RE: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >>> > >>> > >>> > I will join in this effort and urge the members of the community > >to > >>> actively > >>> > participate. Purely technical nor purely court policies and > >procedures > >>> exist > >>> > in a vacuum. Business Policy(fee charging, fee payment...), > >Security > >>> > Policy(trusted partners, arms length...) and Related > >Telecommunication > >>> > Policy all have different Models from which the courts may choose. > >We > >>must > >>> > as a community look at the interactions between these models and > >their > >>> > implications. > >>> > > >>> > Understanding these will prepare us for doing a sound set of > >>requirements > >>> > for Court Filing Blue and the specification that result. > >>> > > >>> > > >>> > Regards, > >>> > > >>> > Don > >>> > > >>> > Donald L. Bergeron > >>> > Data & Systems Architect > >>> > donald.bergeron@lexisnexis.com > >>> > > >>> > 937-865-1276 O > >>> > > >>> > > >>> > -----Original Message----- > >>> > From: Daniels, Dwight (BearingPoint) > >[mailto:drdaniels@bearingpoint.net] > >>> > Sent: Friday, December 20, 2002 3:54 PM > >>> > To: CourtFiling List (E-mail); EFiling Process List (E-mail) > >>> > Subject: [legalxml-courtfiling] EFiling Process Models > >Subcommittee > >>> > > >>> > > >>> > As you have probably seen from John Greacen's summary of the Las > >Vegas > >>> > meeting, the CMS-API subcommittee has undergone a transformation. > >It is > >>> now > >>> > the EFiling Process Models subcommittee. I am tasked with > >composing the > >>> > first draft of the statement of work for the subcommittee and > >>> disseminating > >>> > it prior to the January 6th conference call, but I wanted to take > >this > >>> > opportunity to give you an idea of what the committee's objectives > >are > >>and > >>> > to encourge participation among those interested. > >>> > > >>> > In a nutshell, the committee felt that we needed to get a better > >>> > understanding of the various conceptual process models for > >electronic > >>> filing > >>> > that exist in the community, document those models and compare > >them for > >>> > commonalities and differences. Through this process we will be > >seeking > >>to > >>> > identify the intersection points among the various models and to > >>evaluate > >>> > those points as candidates for APIs to be defined in subsequent > >work. > >>> > > >>> > The focus of this work is not technical. It is process oriented. > >As > >>such, > >>> > the input and assistance of non-technical practitioners is > >crucial. The > >>> more > >>> > we get, the more likely we will be to succeed. I therefore > >strongly > >>> encourge > >>> > those who have a vision for what the business process flow (or > >flows) of > >>> > electronic filing should look like to join us in this effort. > >>> > > >>> > Dwight R. Daniels | Manager | BearingPoint | Costa Mesa, CA > >>> > Office +1.714.957.4835 | Project +1.714.568.5697 | Mobile > >>+1.805.990.9994 > >>> > www.bearingpoint.com > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>************************************************************************** ** > >>> > ** > >>> > The information in this email is confidential and may be legally > >>> > privileged. Access to this email by anyone other than the > >>> > intended addressee is unauthorized. If you are not the intended > >>> > recipient of this message, any review, disclosure, copying, > >>> > distribution, retention, or any action taken or omitted to be > >taken > >>> > in reliance on it is prohibited and may be unlawful. If you are > >not > >>> > the intended recipient, please reply to or forward a copy of this > >>> > message to the sender and delete the message, any attachments, > >>> > and any copies thereof from your system. > >>> > > >>> > >>************************************************************************** ** > >>> > ** > >>> > > >>> > > >>> > ---------------------------------------------------------------- > >>> > To subscribe or unsubscribe from this elist use the subscription > >>> > manager: <http://lists.oasis-open.org/ob/adm.pl> > >>> > > >>> > ---------------------------------------------------------------- > >>> > To subscribe or unsubscribe from this elist use the subscription > >>> > manager: <http://lists.oasis-open.org/ob/adm.pl> > >>> > > >>> > >>> ---------------------------------------------------------------- > >>> To subscribe or unsubscribe from this elist use the subscription > >>> manager: <http://lists.oasis-open.org/ob/adm.pl> > >>> > >>> ---------------------------------------------------------------- > >>> To subscribe or unsubscribe from this elist use the subscription > >>> manager: <http://lists.oasis-open.org/ob/adm.pl> > >>> > >> > >> > >>---------------------------------------------------------------- > >>To subscribe or unsubscribe from this elist use the subscription > >>manager: <http://lists.oasis-open.org/ob/adm.pl> > >> > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: <http://lists.oasis-open.org/ob/adm.pl> > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC