Electronic Presentation
Body of Knowledge |
---|
Document Production Workflow |
Lifecycle Category |
Electronic Presentation |
Content Contributor(s) |
William Broddy m-edp |
Original Publication |
August 2014 |
Copyright |
© 2014 by Xplor International |
Content License |
CC BY-NC-ND 4.0 |
What is Electronic Presentation?
Electronic presentation covers the many ways a document may be presented to a customer on their computer screen, on their phone, on their tablet, or even on their
TV screen. As the delivery of a transaction document moves from physical production and distribution to electronic presentation it is critical that it meet the same business, contractual, legislative and evidentiary requirements of the analogous print and mail process.
The documents we physically create, package and distribute must be:
- Legally presented: there must be a chain of custody to the other party, or to a trusted agent,
- Irrefutable: they must prove who issued them and when,
- Permanent: they must be created in a way that avoids surreptitiously alteration,
- Accurate: the information must be authentic, and
- Usable by the recipient: they must have no encumbrances or dependencies from the issuer.
Proof of Receipt
The mail box, post office or postal rule is a part of the legal rules of evidence in most countries. Courts presume that a document placed into the postal system will be presented to recipient[1] . The issuer of the document only has to provide proof of a chain of custody from the beginning of the creation process through to the posting of the document at the post office. More recent citations require proof that the posted document has the correct address and adequate postage. If these criteria are met, it is presumed that the document has been delivered and the onus is on the recipient to prove that it wasn’t.
Under the Accepted Principles of the Model Law[2], an electronic document is considered delivered “when it enters an information system outside the control of the originator or of the person who sent (it) on behalf of the originator”. If the document is parked on the issuer or issuer agent system, the document is not considered delivered until “the time when (it) is retrieved by the addressee.”
Postal authorities have a unique position in this environment. Common law in most jurisdictions presumes that a document presented to the post office is, in effect, delivered to the recipient. Any electronic document presented to the post office (electronically) to be delivered by them to recipient would be considered presented once in the post office’s possession[3].
Portability
Can the recipient freely read and use the document in the future? Can it be forwarded to another party intact? Can the rule of acceptance be met? A legally presented document must be completely under the control of the recipient. It cannot refer to information that is only available within the issuer’s environment. For example, a bank can’t tell you that you can only see you current monthly statement at the local bank branch and can’t remove it.
Electronic documents that are presented must have the same portability. The recipient’s document must contain all document objects necessary for faithful rendering, at the time of viewing and afterwards when sent to interested third parties. The portability applies to both the information and layout of the document, and the electronic proof of authenticity, such as a digital signature.
Permanence
Can the document’s content, perceivable look or proof of origin be altered? One facet of a paper transaction document is its permanence. It is very hard to alter an electro photographic or ink jet document. The document carries the look and feel that the issuer requires and will contain nuances that are hard to counterfeit. Interested third parties accept it as legitimate: courts accept it as evidence, banks as proof of net worth, accountants and taxation authorities as proof of an expense.
Unfortunately, most electronic communications methods can’t provide this level of permanence. For example, HTML pages are interpreted by the recipient’s web browser. The layout cannot be assured, and critical information may not be displayed. It is very difficult to capture and archive an HTML page in a way that it would be acceptable to many interested third parties, especially if reproduced in the future.
Authenticity
Does the document’s metadata (digital signature) prove who issued the document and when? Was it applied during the normal course of business? Paper documents provide a date of issue, the issuers’ logo and other look and feel attributes. It is delivered by the post office in an envelope that identifies the issuer (hopefully with branding, but at least with an indicia mark).
An electronic document must contain similar proof of its authenticity. The Model Law intends to “allow for the authentication of (a document) by means of a (electronic) signature”[4] and ensure “that a document would be in a form acceptable to public authorities and courts.”
Legibility
Can the document be read or perceived by the recipient as the issuer intended? A printed transaction document is laid out as the originator intended. The composition process ensures that the document layout remains consistent and that the recipient receives a document that is legible and understandable.
One of the intents of Model Law is to ensure in electronic commerce “that a document would be legible by all”[5], and “that a document would remain unaltered over time and provide a permanent record of a transaction ”[6].
In our industry the requirement is to adhere to the above requirements to ensure the electronic documents presented are acceptable to the courts and other interested parties.
Technology Requirements
There are four components to electronic presentation: the format of the document being presented, the process by which the document is created, the mechanism to either deliver the document or a notice to get the document, and the process that ensures that presentation took place.
Formats
The most important technology to decide upon is the document format. It must meet the requirements of the Model Law.
Bitmap Images
BMP, TIFF, and JPG file formats have historically been used for easy delivery across different platforms when there is a requirement to store a record of the document exactly “dot for dot”, i.e. the electronic version viewed on a computer monitor should be an exact match to the document created on the printer.
This method has gone out of favor as there is no universal standard on what bitmap image format is the best to use and therefore no standard on reading software. Bitmap images of individual pages means that they are typically large in file size when compared to other methods of storage and delivery. This format also lacks the ability to contain metadata in a standard way within the file itself.
However, bitmapped images digitally signed with proof of originator and time of transmission, meet most of the criteria laid out in the Model Law.
Object-oriented Documents
The most common formats delivering final-form documents are variants of Adobe Portable Document Format (PDF), although presentment solutions do exist for AFP.
PDF, governed by ISO standard 32000-1[7], has been widely accepted as a format for presenting final form documents. However, there are many flavors of PDF that are provided by composition or transform utility suppliers. At the lowest level, there are PDF files that contain nothing more than a TIFF image for each page. Although viewable, they are large and have no search capability. At the high end, there are PDFs that contains objects that may require special extensions or viewers. Although PDF files do provide a final format they can be altered unless properly locked.
A properly structured PDF that is digitally signed through a credible process may meet the evidentiary requirements of the Model Law. However, the onus is on the issuer and software provider to prove the authenticity of any questionable document.
PDF/A(rchive)
The need for permanent, legible, authenticated documents is a requirement in most business and government environments. Corporate records management systems must meet these standards. The Food and Drug Administration requires so much original documentation that the paper evidence for a drug submission used to fill two semi- trailers. Because records managers, regulatory agencies, and government archives need an electronic alternative, they were instrumental in driving much of the wording in the Model Law and in defining the business requirements for PDF/A.
PDF/A is an ISO-standardized version of PDF designed for the digital preservation of electronic documents. The latest standard is PDF/A-3[8].
PDF/A differs from PDF by omitting features ill-suited to long-term archiving, such as font linking (as opposed to font embedding). The intent is to ensure that a PDF/A document can be opened 100 years from now and still be legible.
The ISO requirements for PDF/A file viewers include color management guidelines, support for embedded fonts, and a user interface for reading embedded annotations.
A properly implemented process that creates PDF/A documents in the normal course of business should meet all the requirements of the Model Law. It has been adopted by the government in the United Kingdom[9], the US Federal courts, the US Food and Drug Administration, and the US National Archive among other large regulatory organizations. PDF/A is evolving into a presumptive standard for authenticating evidentiary documents, putting the onus on the disputing party to prove that the document is fraudulent[10].
Semi-formatted Presentation Formats
HyperText Markup Language
HTML is a web-based file structure that depends on the recipient’s web-browser software to lay out the document. As originally implemented[11] it uses tagged logical commands to decide which font / size / weight to use. The file is marked up with tags to allow the web-browser to adjust the layout based on the display technology and user preferences. The heading <h1> in Figure 2 does not say where the line of text will be placed, what font / size / weight / color to use. This is left up to the browser’s settings.
The information presented may be perceivably different from one browser (Internet Explorer) to another (Chrome) and one technology (Windows) to another (Android, IOS or BB10). The layout is not permanent.
Also, web-based information is not portable; many of the relevant resource objects are not contained within the file, but linked at the issuer’s website. If the recipient saves the document “for subsequent reference”, these resource objects may not be available if the recipient tries to look at the document offline, the issuer removes the objects from their website, or blocks the recipient, or interested third party, from retrieving the objects (e.g. the recipient no longer has an active account, or the interested third party cannot log into the recipient’s account). Below is example of HTML.
<!DOCTYPE html> <html> <head> <title>This is a title</title> </head> <body> <h1>So Long</h1> <p>and thanks for all the fish</p> </body> </html>
The HTML files do not contain a digital signature that would authenticate the issuer, time of issue, and integrity of the contents. This information is carried in the transmission layer (S/HTTP) and does not stay with the file once it is saved.
Finally, browser recipient settings may cause the information in HTML file to display in a way that is impossible to understand (e.g. browser accessibility feature may remove background (CSS?) layer that provides key static information or changes all shaded fonts to 100% black). This may cause the document to be illegible.
Extensible Markup
XML has a tag structure similar to HTML except that it only provides a way to define tags for specific environments. It provides the syntax that various XML Schema (something like a profile) must follow in creating new tags. There are hundreds of XML Schema in use, many of which are transparent to us. In most cases, the tags within the Schema are used to logically define data, not place it. To use XML-defined data requires the use of an eXtensible Style Language (XSL) file. To use an XML file to present a legally relevant document has most of the portability and authenticity limitations of HTML
Creating the Electronic Document
The two most common ways to create an electronic document are to compose it or to transform an existing print file into PDF.
Composition
Most current composition products used to generate transaction documents offer PDF, PDF/A, HTML, XML, and TIFF emitters. If you have one of these products, it is likely that you can generate PDF and PDF/A that are perceptively identical to their printed counterparts.
You can also generate HTML and XML that can be fed to an external system that displays the file. The end result might even look like what you intended. It will not, however, have the look and feel of the printed equivalent circulating in the marketplace. It will also have all the limitations identified above.
Transformation
Many transaction document applications run on legacy platforms. Still others use COBOL, C and even PASCAL programming to generate documents. The most practical way to create electronic documents from these applications is to transform the existing print file into the desired format.
There are many excellent transaction document print stream transformation tools that do this. You should ensure that they create more than images of each page in the file.
Presenting the Electronic Document
There are a few ways to deliver legally relevant electronic documents. If you have created a document that is both portable and has proof of authenticity, you must present it in a way that ensures timely delivery, and can be proven.
Internet Email
Although sending email correspondence is well established as a reasonable way to communicate, there are some inherent limitations around proof of delivery.
The most common method of sending email is using Simple Mail Transmission Protocol (SMTP). This allows an email object to be submitted to the Internet where it will eventually be presented to the recipient’s email server. Along the way, a copy of the email is temporarily left on every server it touches.
Once it gets to the email server, the email may be considered spam and quarantined or erased, or it may be approved and held for the recipient to retrieve, using either POP3 or IMAP.
Unfortunately, SMTP provides no chain of evidence back to the issuer, only to the recipient. Although a read receipt is possible the issuer is dependent on the recipient to allow the response to the request. Email formatted as HTML may not actually reach the recipient’s email system.
HyperText Transmission Protocol Secure
Web browsers use HTTP to call a file for viewing. The browser must use an HTTPS call when the webpage contains or requests sensitive information. HTTPS provides authentication of the webpage owner (through a third-party-issued digital signature) and provides bi-directional encryption between the browser and the server.
HTTPS can be used to call HTML, PDF, and XML files.
HTTPS is a passive process. It requires the recipient to proactively fetch the document from the website. The recipient may not visit their mailbox frequently. This affects the recognized time of presentation, depending on whether the document is parked on the issuer’s server, or on a third party server that is arms-length[12] from the issuer. For the former, the time is when it is retrieved, for the latter it is the time that it is presented to the third party.
Inverted Pull
The most popular way to present electronic mail is to put the document into a web- based mail-box, then send an email to the recipient inviting them to “pick up their new mail”. You should not include an HTTP link in the email as this would open the process to spoofing[13].
Mobile Apps
The third option is to use a mobile application that constantly looks for mail at third party server and pulls it onto the recipient’s appliance.
This type of app would use strong encryption, and would immediately receive the document on behalf of the recipient. The app would hopefully also properly store the received documents in a way that provides subsequent use.
Proof of Receipt
A legally relevant document must not only be presented, but there must be proof of presentation. The mail box rule makes this much easier for presentation of paper documents; you only have to prove they all got to the post office. However, this is not the case for documents sent directly from the issuer. It’s still unclear whether third party providers[14] will be recognized as an agent of the recipient (who gets the mailbox for free) or the issuer (who pays for delivery).
With SMTP, there is a high risk that the document will never arrive, and there would be no chain-of-custody available to the issuer. Proof of receipt is very risky.
With HTTPS, there is a clear chain-of-custody from point at which the recipient calls the document. However, there is an indeterminate latency of receipt waiting for the recipient’s call.
With Mobile (and PC) Apps, there is a clear chain-of-custody and there is no latency. It will be interesting to see applications in this area mature into robust consumer receive and archive management systems.
References
- ↑ Example of Mail Box Rule being cited in court rulings: No. 10-5205. United States Court of Appeals, Sixth Circuit - SOLOMON OLIVER, Jr., Chief District Judge Filed: October 6, 2011 - “For the presumption of receipt to arise under the common law mailbox rule, a party must present evidence that the letter was “properly addressed, had sufficient postage, and was deposited in the mail”. WIGMORE ON EVIDENCE states: “The presumption [of receipt] rests upon the supposed uniform efficiency of the postal service in delivering letters duly stamped, addressed, and mailed into its custody; if therefore the efficiency is operating, does not the non-arrival of an alleged letter indicate that such a letter was never given into the postal custody?”
- ↑ UNCITRAL Model Law on Electronic Commerce. http://www.uncitral.org/+uncitral/en/uncitral_texts/electronic_commerce/1996Model.html
- ↑ Canada Post’s ePost offering is an example of this. http://www.epost.ca
- ↑ UNCITRAL Model Law on Electronic Commerce, Section 47 – Point 6
- ↑ UNCITRAL Model Law on Electronic Commerce, Section 47 – Point 4
- ↑ Ibid Point 7
- ↑ ISO 32000-1: 2008. Document management -- Portable document format -- Part 1: PDF 1.7
- ↑ ISO 19005-3:2012 and is based on ISO 32000-1 – PDF 1.7. There is also PDF/A-1 (2005) and PDF/A-2 (2011)
- ↑ For static versions of non-statistical data produced for download, archiving and authenticity, PDF/A should be used as the default for non-editable documents, http://standards.data.gov.uk/proposal/viewing-government-documents
- ↑ This should not be considered a legal opinion.
- ↑ RFC 1866 - Hypertext Markup Language - 2.0 I
- ↑ The key test of this is whether the issuer can request already delivered documents to be deleted and replaced. One you mail a letter (with a correct address and adequate postage, it cannot be returned).
- ↑ Someone sending out an identical email with a link to a ‘bogus’ webpage. They would capture the sign- in information, and then pass the victim to the correct page. The villain then has all of the victim’s sign-in information and can peruse their financial correspondence looking for identity information.
- ↑ One exception is Canada Post’s ePost mailbox system, which is considered the equivalent of Canada Post physical mailboxes. This may also apply to other postal authorities’ electronic mail box offerings.