Definition

An e-Document is any electronic document, structured or unstructured, which supports various formats and it is support functionality that fulfils a set of generic, domain or use case specific requirements.

Thus an e-Document carries information as payload and supports functions to be used in processing and presenting the information to the end-user, functions exposed as e-Document services.  Therefor we may refer to e-Document as ‘e-Document as information’ or ‘e-Document as a service’.

There are two parties or roles involved in an e-Document transaction, an e-Document producer and an e-Document consumer.

The producer is responsible for creating and maintaining an e-Document.  Different actors can be associated with the producer’s role, such as the authors, contributors or document signers.

The e-Document consumer is acting on the e-Document with the purpose of processing it accordingly to his needs. A consumer may be a computer system that automatically processes the e-Document as well as an end-user.

To guarantee the interoperability, the data protection and data privacy, a binding contract must exist between the producer and the consumer. By contract the two parties are agreeing upon the e-Document exchange format, the method of exchanging or delivering the e-Document, the methods of assuring the authenticity and non-repudiation of the information and other issues of importance to the parties.

 

Objective

This document provides with a solution architecture template to be used by solution architects in creating interoperable and re-usable building blocks that support the handling of e-Documents by the public administration. It provides with a common and unambiguous terminology and approach to cope with the interoperability needs of e-Document services and it presents a holistic view on interoperability of electronic documents across European member states. 

 

 

Name:e-Document
Version:0.6.0
Status:Construction 2
Set of ABBs:

Document Provisioning

Document Business Envelope

Document Container

Generic requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section of the document are to be interpreted as described in [RFC2119].

Requirement
ID

Requirement description

Compulsory

Source

 

R-eDoc-T1

The structuring of e-Documents MUST make use of common standards ( such as XML).

Yes

R5.1-UC3-7, R5.1-UC3-34

R-eDoc-B1

The exchange format SHOULD be based on common standards, inline with EU standardization policies.

Yes

R5.1-UC3-11, R5.1-UC3-10

R-eDoc-B2

Spread sheet format COULD be used as exchange format.

No

R5.1-UC3-25, R5.1-UC3-26

R-eDoc-T2

A structured e-Document in XML format MAY be converted to RDF based format.

No

R5.1-UC3-29

R-eDoc-T3

An e-Document in spread sheet format MAY be converted to XML format.

No

R5.1-UC3-28

R-eDoc-B3

The e-Document producer MAY associate schematron rules to the e-Documents that can be used by e-Document consumers to automate the process of validation of the documents.

No

R5.1-UC3-9

R-eDoc-B4

The e-Document producer MAY annotate structured data elements inside e-Document or can annotate at document level.

No

R5.1-UC4-3, R5.1-UC4-48, R5.1-UC4-91

R-eDoc-B5

The e-Document producer SHOULD have tools for validating the e-Document exchange format before sending it the consumer.

Yes

R5.1-UC3-17

R-eDoc-B6

The e-Document producer MAY use multiple keys and algorithms to encrypt parts of a structured e-Document.

No

R5.1-UC1-45

R-eDoc-B7

The e-Document structured data elements MAY be versioned.

No

R5.1-UC4-96

R-eDoc-T4

The producer MAY safely embed other documents as binary objects or external links (URIs) into structured e-Document.

No

R5.1-UC4-47

R-eDoc-T5

The structured e-Documents MAY be presented using XML style sheets.

No

R5.1-UC3-8, R5.1-UC2-3

R-eDoc-T6

The consumer SHOULD easily identify the schematron rules associated with the e-Document.

Yes

R5.1-UC3-9

R-eDoc-B8

The consumer MAY use schematron rules to validate the e-Document.

No

R5.1-UC3-9

R-eDoc-T7

The consumer SHOULD easily identify the annotations associated with the e-Document.

Yes

R5.1-UC4-3, R5.1-UC4-48, R5.1-UC4-91

R-eDoc-T8

The consumer SHOULD easily identify the encrypted parts which are addressed to him.

No

R5.1-UC1-45

R-eDoc-T9

The consumer MAY decrypt the data with the appropriate keys.

Yes

R5.1-UC1-45

R-eDoc-B9

The consumer SHOULD have tools to present and process the structured documents.

No

R5.1-UC3-12

R-eDoc-T10

The consumer SHOULD easily identify the binary objects or the external links embedded into an e-Document.

Yes

R5.1-UC4-47

R-eDoc-B10

Document packaging MUST be based on common standards, inline with EU policies.

Yes

R5.1-UC 2-9

R-eDoc-B11

The e-Documents and associated metadata MAY be wrapped up or packed into a single document as a container format.

No

R5.1-UC2-4, R5.4-UC1-12, R5.4-UC2-12, R5.4-UC1-11, R5.4-UC2-11

R-eDoc-T11

The container SHOULD be easy to unpack in order to extract, present, validate and process the e-Documents inside.

Yes

R5.1-UC2-6, R5.4-UC1-12, R5.4-UC2-12

R-eDoc-T12

The container SHOULD be structured in such way it makes it easy to separate and differentiate between the e-Documents which are holding the actual information and those structured documents holding the metadata (generic or domain specific metadata, information about attached signatures and timestamp, process and business rules, validation rules, annotations, etc.).

No

R5.4-UC1-11, R5.4-UC2-11

R-eDoc-T13

The container SHOULD support the attachment of advanced electronic signatures such as XAdES, CAdES and PAdES.

Yes

R5.4-UC1-39, R5.4-UC2-39

R-eDoc-T14

The container SHOULD support the attachment of trusted timestamps.

Yes

R5.4-UC1-42, R5.4-UC2-42

R-eDoc-B12

The container SHOULD have the same generic requirements as other e-Documents.

Yes

 

R-eDoc-B13

The container MUST support the packaging of both structured and unstructured e-Documents (scanned documents).

Yes

R5.4-UC1-15, R5.4-UC2-15

R-eDoc-B14

The container SHOULD support logging operations from consumers such as back the office validations in business lifecycle domain.

Yes

R5.4-UC1-12, R5.4-UC2-12

R-eDoc-B15

The container SHOULD support encryption of the e-Documents it holds.

Yes

R5.4-UC1-41, R5.4-UC2-41

R-eDoc-T15

The container SHOULD support the validation of the documents integrity by using cryptographic hash functions per document basis.

Yes

 

R-eDoc-B16

The domain or use case specific behaviour of the e-Document SHOULD be captured and described as a profile.

Yes

R5.1-UC1-2, R5.1-UC1-19, R5.1-UC4-95

R-eDoc-B17

Document profiling SHOULD be based on common standards, inline with EU policies.

Yes

R5.1-UC4-104, R5.1-UC1-3, R5.1-UC1-4, R5.1-UC1-5, R5.1-UC1-6, R5.1-UC1-20, R5.1-UC1-22

R-eDoc-B18

The e-Document producer SHOULD use identifiers so that the consumer can easily identify the right information.

Yes

R5.1-UC1-2, R5.1-UC1-19,
R5.1-UC1-28

R-eDoc-B19

The profiled e-Document information SHOULD be self sufficient and consistent.

Yes

R5.1-UC4-50, R5.1-UC4-92

R-eDoc-B20

Where possible, the producer SHOULD use the interoperability solutions from ISA such as the core vocabularies (Business, Organisation, Location, Person).

Yes

R5.4-UC1-22, R5.4-UC2-22

R-eDoc-B37

The producer MAY request the proof of delivery from the consumer.

No

R5.1-UC1-28

R-eDoc-L1

The producer MAY request for the acknowledgment by the consumer of the e-Document information.

No

R5.1-UC1-28

R-eDoc-L2

Upon request, the consumer SHOULD provide with the proof of reception and the acknowledgment of the e-Document information.

Yes

R5.1-UC1-28

R-eDoc-T16

The producer MAY associate routing information with the e-Document so that the delivery system may route the documents to the right consumers.

No

R5.1-UC4-49

Use Cases and Scenarios

Basic generic use case

Use Case

Basic use case of the e-Document solution

Description

Producer workflow:

  1. Providing the document:
    1. structure and describe the document using semantic tools;
    2. transform to agreed exchange format;
    3. add annotations or free text to data level in the document;
    4. add processing rules;
  2. Secure the document:
    1. attach timestamps and signatures;
    2. encrypt the document;
  3. Send the document:
    1. validate the document and resulted metadata files;
    2. package the document and the metadata files into an e-Container format;
    3. send the document to the document consumer using an electronic delivery solution. 


Consumer workflow:

  1. Receive the document:
    1. unpack the document;
    2. validate the document and the metadata files;
    3. acknowledge the reception of the document;
  2. Process the document:
    1. process metadata and rules;
    2. process data and information;

Actors

  1. Document producer
  2. Document consumer

Goals

Prove basic and general functionality for an e-Document used in an administrative process.

Assumptions

Sending and receiving the document are processes which are using information delivery solutions such as e-Delivery.

Artefacts

e-Document instance.



 

Detailed usage of the e-Document with more value-added functionality

Use Case

Combined use case for sending and receiving an e-Document packed in a container format and delivered using e-Delivery gateways.

Description

The e-Document author starts with identifying the tools and the profile he needs, given the context where he wants to structure a scanned document, annotate the document, sign and encrypt the document and deliver it:

  • the transformation and structuring tool to describe the scanned document;
  • the annotation tool;
  • the validation tool;
  • the digital signing tool;
  • the encryption tool;
  • the container format;
  • the document routing envelope tool.


Producer workflow:

  1. The author uses the structuring tool to create a metadata document which describes the scanned document. Beside generics, the generated metadata will contain also domain specific descriptions and this is possible because the author has used correctly the document profiling. Because the author wants the document consumers to acknowledge the receiving of the document, he is adding a special description in the metadata;
  2. He then adds a comment to the document that he knows it could help the receiving party in a human decision making. He also adds some notes at data element level. To do all these he is using the annotation tool;
  3. With the signing tool the author digitally signs the scanned document. The tool will automatically attach the author's signature(s) and will update the metadata to correctly reference the signatures;
  4. For security reasons the author encrypts the scanned document using encryption keys shared with the document consumer as agreed in the contract. The encryption algorithm is has been also pre-agreed;
  5. Before packaging all the documents into a container format, the author validates that all data is consistent with the requirements and constraints of the e-SENS e-Document;
  6. Using the e-Container, the author is wrapping all documents into a single document. The e-Container will automatically generate a hash code for the scanned document and will add it tot he metadata so that the receiving party might check fort he document integrity.
  7. The author wants to deliver his container using the e-SENS e-Delivery solution to two different competent authorities from a different EU member state so he will be using the document routing tool;
  8. The author sends the container using e-Delivery. He receives the confirmation of delivery immediately. Later on, he will also receive a confirmation from the two competent authorities that the document is valid and readable.


Similar to the producer, consumer will mostly use the same tools for unpacking the container, validating, checking signatures, decrypting the document and presenting it to the end-user.

Consumer workflow:

  1. The competent authority (CA) receives the routing envelope and extracts the container from it. It then unpacks the container to the CA local storage in order for other application to easily access the container files;
  2. Before using the container, the CA will validate it to make sure the container structure and files have not been corrupted. Fort that the CA is using a validation tool that will check if the document hash that it has been declared in the metadata matches the newly computed hash;
  3. By checking the validity of the signatures the CA makes sure the document is authentic;
  4. In order to present the document to the end-user, the CA hast o decrypt the scanned document using the keys provided by the e-Document producer;
  5. The end-user will view the scanned document using and external tool (such as a pdf viewer) and the associated metadata in an internal application;
  6. Because there is a „flag" in the metadata indicating the need to send an acknowledgment that the document can be viewed, the CA will send a notification to the producer.

Actors

  1. e-Document producer/author:
  • Contributor;
  • Validator;
  • Signer ;

2. e-Delivery infrastructure:

  • Sender's gateway;
  • Receiver's gateway;

3. e-Document consumer:

  • Competent authority.
    In our use case the person who contributes to the creation of the e-Document is also the person who validates the document and also the person who digitally signs it.

Goals

  1. Describe an unstructured document using semantic tools;
  2. Use of advanced signatures and encryption to improve security;
  3. Use the e-Delivery solution and the national gateway infrastructure to deliver the e-Document.

Assumptions

  1. The e-Delivery infrastructure is deployed;
  2. There is a contract between the document producer and document consumer and they set up the required procedures to ensure that:
    • they can exchange documents;
    • both use the same domain profiling and document exchange formats;
    • the encryption keys have been exchanged;
    • they can identify each other.

Artefacts

  1. The container file:
  • The encrypted scanned document;
  • Generic and profile metadata document;
  • Attached electronic signatures;
  • Annotations document;
  1. The confirmation of the delivery which is generated by the receiver e-Delivery gateway;
  2. The receipt of acknowledgment generated by the e-Document consumers;
  3. The routing envelope.

 

 


Solution patterns and variability

Message-oriented document

An e-document instance may carry short-lived messages that are intended to be consumed in a programatic way by the recipient. This implies the message-oriented document is structured and each element of the e-document structure or schema has been agreed and incorporated into the contract between the e-Document producer and consumer.

The message syntax or the e-document schema should be based on existing core vocabularies. 

An example of a message-oriented document is the e-Confirmation document format.

Architecture building blocks that may be used:

  • The Document Provisioning ABB must be used for creating the message syntax;
  • The Document Container ABB may be used in case there is a requirement for attaching additional documents to the message such as signatures, additional metadata, schematron rules, annotations, etc. If no additional information is needed it is recommended not to use the container as it is adding up to the complexity;
  • the Document Business Envelope should be used when using e-Delivery or when high level metadata describing the business context of the document is needed.

 

Semantic-oriented document

The semantic-oriented document holds all the business information structured using semantic vocabularies and ontologies. Such document should have the data entities addressable using unique identifiers so that the document is queryable. 

Though it is clear the consumer should be aware of the e-Document structure in order to properly bind the data, it is not mandatory however to be part of the schema negotiation process which can be done exclusively by the producer.

The Virtual Company Dossier e-document format is a practical example of how a semantic-oriented document looks like. 

A semantic document may be seen as a more complex message-oriented document and similar to it does require Document Provisioning ABB for structuring. The Document Container and the Business Envelope are optional.

 

Metadata-oriented document

This pattern is focusing on the metadata that describes a document that may be unstructured, like a PDF document and which has been generated in a different business context. The Business Lifecycle use case is making use of this architecture pattern, where the metadata is used for automatic data and process orchestration while the actual document is used as evidence and human interpretation.

Because such an e-Document consists of more than one document, it is strongly recommended to use Document Container to keep the document logically and physically grouped. 

Document Provisioning is another ABB that is mandatory to be used in creating the metadata structure.


Archive-oriented document

This type of document can be any of the document types described before with special focus on preserving the information for longer periods of time.

Orchestration and topology variability

The services the e-Document is offering are realized by a set of casually activities or business processes such as:

  1. Document transformation and structuring:
    1. Convert an e-Document to another format;
    2. Transform the e-Document to the necesary exchange format as agreed in the contract between producer and consumer;
    3. Structure and describe a document using semantic tools (schemes, vocabularies);
    4. Annotate the document;
    5. Attach validation and business rules (schematron rules, business rules that can be executed by a BRE Business rules engine);
  2. Document presentation and processing:
    1. Validate against the schematron rules;
    2. Process the business rules;
    3. Extract structured information and make it available to the end-user;
    4. Present the document to end-user in a standard format;
  3. Document packaging:
    1. Sign and encrypt the document;
    2. Validate the authenticity and the document integrity;
    3. Pack all documents and metadata derived into a container format;
  4. Document profiling:
    1. Offers guidelines and „best practice" in extending and profiling the e-Document functionality to specific domains or use cases;
    2. Profiles and extensions for the existing e-SENS pilots such as Business Lifecycle and e-Procurement;
  5. Document routing:
    1. Add the information needed for routing the document;
    2. Embed the e-Document into the routing envelope.

 

The e-Document solutions are constrained to realising the e-Document services: transformation and structuring, presentation and processing, profiling, packaging and document routing.
Thus, the following architectural building blocks have been identified which support the corresponding application services:

  1. Document Provisioning ABB: it describes how to produce (transform documents and structure) and consume (present and process) an e-Document. The reason for merging the producer and consumer's functionality is because part of it is common to both (e.g. the validation, transforming a document to another format, etc);
  2. Document Container ABB: specifications for the container format;
  3. Document Business Envelope ABB: specifications for the routing envelope;
  4. Use case or domain profile document: is an architectural artefact that holds specific technical requirements, specifications and guidelines that can be used in implementing a solution needed for instantiating and the usage of e-Document instances. The profile is created using the Document Profiling methodology.

Use case or domain profiling overview

 

In realizing a solution for e-Document, the implementer could use several e-SENS building blocks such as:

  • e-Signature for the creation and the validation of the signatures;
  • e-ID for authenticating end-users;
  • e-Delivery for delivering e-Documents through national or local gateways;
  • Trust Services for the timestamp tokens;

However, other solutions could be used as well for each process and it is recommended the implementer should design in such way it is easy to use different service providers (e.g. one solution could use e-SENS e-ID service, other solution could use STORK service) following specific software design patterns such as the adapter and the bridge pattern.

 

 

Contributors

Name

Surname

Organisation

Country

Radu

Boncea

ICI Bucharest

Romania

Klaus

Vilstrup PedersenDIFINorway
PanagiotisNicolaouUPRCGreece

History

Version

Date

Changes made

Modified by

0.2.0

17.03.2014

Template

Klaus

0.3.0

15.07.2014

Added the description for e-Document HBB. Added risks and stakeholders log.

Radu Boncea, Panagiotis Nikolaou

0.4.0

18.08.2014

"CAN" replaced with "MAY" to be consistent with RFC2119.
Removed the risks and stakeholders log that are to be included separately in EIRA.
Aligning to Rome template and EIRA requirements.

Radu Boncea

 

0.5.017.12.2014Aligned to the EIRA solution architecture template.Radu Boncea
0.6.017.04.2015Aligned to new reference architecture template and integration into the repository.Radu Boncea
  • No labels