This chapter will analyze and describe
trade scenarios and processes relevant to the control of the trading of CITES-listed
Analysis of these questions may be useful
to Parties implementing (to-be) or further developing (as-is) national
electronic permitting systems. The resultant process description can assist in
answering the following questions:
The main groups involved in the CITES
e-permit process are traders (B = business level) and Customs, CITES Management
Authorities or other governmental bodies (G = governmental level). These groups
can interact with each other in specified ways.
Relationships or interactions among those groups
can take place on different levels. The level of interaction (B2B, B2G and G2G) within the scope of a particular e-permit implementation will
influence the technical and security aspects of that CITES implementation.
The international trade process in regard
to the CITES Convention can be summarized in two main directional processes:
the import and export (or re-export) of CITES-listed species.
Currently, in the B2B and B2G scenarios most
of the data exchange processes in many CITES implementation environments are paper
The introduction of electronic data
exchanges will create opportunities for more sophisticated solutions and higher
level interactions such as G2G or inclusion in the Single Window concept as supported
through G2G data exchanges.
Furthermore, in the following description of the technical process, attention is given to potential impacts of implementation on the different process scenarios. Attention is also given to how a choice of a solution for a particular environment may be dependent on compatibility and security needs.
The process diagrams assist in visualizing and clarifying issues related to implementation of e-permit systems of the current situation of an existing implementation. It also assists in identifying potential optimizations by enhancing current paper-based processes with electronic data exchange in different scenarios.
electronic permitting system requires first and foremost the unambiguous
definition of, and the structural relationships between the pieces of
information which are used across the CITES trade and administrative processes.
These definitions and structural relationships can be provided by either an
ebXML compliant or a WCO Data Model compliant CITES payload syntax neutral subset
data model (see Chapter 4 Annexes). Such a CITES e-permit data model subset offers
the blueprint for the implementation of compliant and interoperable systems of
To be able
to exchange CITES data between CITES Authorities and other bodies/agencies
nationally and internationally, it is necessary to define a technical exchange
format for the data. This is provided by a World Wide Web Consortia (W3C)
compliant and ebXML conformant CITES XML schema.
relationship between the CITES payload syntax neutral data model and the CITES
XML schema is that the CITES XML schemas have been fully auto-generated from
the CITES or WCO data model subsets. The key reason for this standards approach
is that, by keeping the underlying CITES data model consistent and free of
technical errors, and by generating the CITES XML schema automatically from it,
maintenance becomes easier and cheaper than if the XML schema were generated
and maintained manually.
the distinction between a payload syntax neutral data model and the XML
exchange format allows the use of the CITES data models as a canonical format
for the mapping to (or even the generation of) other payload grammars, such as
other W3C compliant schemas, other XML schemas, ISO XML, comma-delimited
exchange formats (CSV) or classic EDI formats such as UN/EDIFACT. Another
reason is that the innovation cycles related to the Internet and XML
environments are very short and the use of a payload neutral model is more
likely to be adaptable to technological change.
The first of
the two CITES data model subsets is based on the UN/CEFACT Core Component
Library (CCL) which is compliant with ISO 15000 ebXML Core Component Technical
Specification (CCTS). The UN/CEFACT Core Component Library (CCL) has been set up as a library of reusable data structures by harmonizing submissions from
trade, transport, insurance, tendering, tourism, government agencies like
Customs or phytosanitary and many others.
of the two CITES data model subsets is based on the WCO Data Model version 3.3
which is recommended for supporting implementation of International Trade
Single Windows systems.
The CITES CCL
based data model presented in this toolkit defines a restricted profile of the
UN/CEFACT CCL version D12B and it contains only the data structures and
elements which will be needed for the exchange of CITES data. The CITES UN/CEFACT
XML schema presented in this toolkit is conformant to the UN/CEFACT XML naming
and design rules.
WCO Data Model subset presented in this toolkit defines a restricted profile of
the WCO Data Model version 3.3 and it contains only the data structures and
elements which will be needed for the exchange of CITES data. The CITES WCO XML
schema presented in this toolkit is conformant to the WCO XML naming and design
GOVCBR subset presented in this toolkit defines a restricted profile of the
UN/EDIFACT standard message GOVCBR and it contains only the data structures and
elements which will be needed for the exchange of CITES data. The CITES GOVCBR Message
Implementation Guide (MIG) presented in this toolkit is conformant to the UN/EDIFACT
The reuse of
any of these CITES data exchange specifications for e-permitting
implementations supports greater interoperability across all the sectors,
parties and boundaries of Cross Border Trade. The two provided CITES data
models and the three syntax specific exchange specifications provided in the Chapter
4 annexes are fully aligned to each other. The UN/CEFACT based data model may
be the most appropriate choice for trader to CITES Authority data exchanges and
the WCO based data model may be the most appropriate choice for the CITES
Authority data exchanges with other CITES Authorities or Customs etc.
The CITES and related Customs and other governmental
agency scenarios are exchanging nearly identical data structures, which are
basically consignment based. In other words, both the electronic and paper
documents are profiles of the same basic structure. The CITES e-permit XML
schemas and the GOVCBR MIG specification each cover all the data needed to
describe the exchange of CITES relevant information referring to the processes
of an import, export, re-export or other types of CITES permit processes and
for all cases in regard to the CITES appendices.
The provided specifications may not cover
all possible specific national requirements where they may differ from the
CITES standard because of the variety of national rules and regulations.
However, where known, some specific requirements for national or regional
implementations have been included.
Future more advanced scenarios with
extended data requirements may be developed, such as providing XML schemas for
Web services to include queries to the CITES Trade Database or other relevant
databases. The CITES e-permitting data exchange specifications may then be the
subject of further development to include these new requirements.
By design, the CITES e-permitting data
exchange specifications support Single Window environments and international
trade-related data interoperability. They have been designed to maximize their suitability
for future data exchange requirements.
However, the scope of this project is defined
pursuant to Decision 14.55. The CITES e-permitting data exchange specifications
described in this toolkit concentrate on providing the necessary
interoperability of data in B2G and G2G interactions.
In practice, XML schemas are commonly developed
for two usages which can be human-related and application-related. From a human-related
perspective, XML schemas offer a human-readable presentation of exchangeable
data structures and its documentation. Furthermore, applications can be
supported by document structures which are expressed in XML schemas.
The CITES e-permitting data exchange
specifications have been developed to meet as many of the above criteria as
possible. In the opinion of the Secretariat the chosen combination of the reuse
of these e-permitting data exchange specifications offers a flexible and future
looking way forward.
Applying a new technical CITES (e-)permit system
may have impacts on processes of other parties such as Customs authorities.
Business procedures or technical implementations may have to be changed and the
readiness of other parties to adopt the new solutions has to be checked before.
From the view of the CITES Management
Authority the following parties may have specific interests in communicating to
Generally, all parties need to be able to:
Additional features and options for exchanging and processing CITES data more efficiently may be offered to participating partner agencies. Some important options which could be available include:
Other CITES Management Authorities
It is possible to identify the following
data exchange scenarios all of which may be relevant to CITES e-permit system
B2G in the
context of CITES data exchange means a business party (e.g. exporter/importer)
G2G in the context of CITES data exchange can have two connotations
which can be referred to as the ‘external’ G2G and the ‘internal’ G2G.
case is when there is an interaction between a CITES Management Authority of
one country (e.g. the exporter country) and the CITES Management Authority
(e.g. the importer country) of another country.
case is when there occurs data exchange internally in a country between its
CITES Management Authority and related national governmental agencies.
Applications, interfaces and possible data exchange technologies are factors which may define the implementation of a CITES e-permitting system. All typical components of data exchange must be defined including the data exchange format, the chosen data transfer protocol and the data input and output application, among others.
of an electronic CITES permit form involves the conversion of the data fields
present in the paper document into a suitable electronic format which provides
a more convenient way for a user to insert his/her data values. The required conversions
include the implementation of ‘tick boxes’ into radio buttons and the addition
of drop-down code lists. Business rules can also be integrated into the e-form
definition so that data validation can be built in to increase the accuracy of
the submitted data and for increased ease of use. The data may have to be
inserted manually into the resultant interactive document (e.g. PDF e-form) or,
alternatively, there may be direct linkages to the data through the use of an
an XML file can be created easily and transferred electronically as an e-mail
(SMTP) or more directly via the Internet (HTTP, HTTPS).
transfer of the XML file or an interactive document should be carefully
considered and all necessary security methods employed such as https, digital
signature or smart card. The security method will determine the choice of the
The implementation of an e-form solution has only low-level, readily available and reasonably low-cost technical requirements such as PDF reader software, an Internet connection and an Internet browser.
A Web application provides an efficient way of implementing e-permit
procedures. The user has easy access to his/her e-permit status information via
a Web application using a login name and password. All data entry can be done
using one online application which is accessible via an Internet browser.
Master user data could be submitted once, saved and maintained in a
database and reused several times. An interaction between different documents
and e-permit tasks could be created and a history logged to provide statistics
The technical requirements are the Web application, an Internet
connection and an Internet browser.
The usage of a Web application can generate some drawbacks such as the need for access to the Internet or an intranet. Another disadvantage may be that if there media breaks occur between two data exchanging parties, it may be necessary to re-enter the data a second time.
Web service technology
allows the connection of applications by communicating via a network. A Web
service can be used to transfer and process CITES data automatically without a manually
initiated user request or response actions.
A good example
of a CITES Web service would be the automated lookup of CITES scientific names
of species directly from a drop-down menu of an e-form.
aspects and data transfer protocols should be considered carefully.
The requirements of the usage of Web services are: to be online and to have real time database access not only on the side of the data provider but for the data retriever, too.
There are possibilities
for significant improvements of the CITES e-permitting processes through the
implementation of a Single Window approach.
A Single Window in an international trade regulatory
environment can be described as a facility that allows all traders to submit
their regulatory required information electronically with each piece of
information submitted once and only once through a single entry point.
From a CITES perspective a Single Window
can either be a single CITES Management Authority or a wider national or
regional Single Window covering Customs and other related regulatory bodies.
If a CITES Single Window is in place an
importer or exporter can use the Single Window as an entry point for submitting
e-permit requests and for receiving responses from the MA. The submitted data
will be processed directly by the Management Authority. Depending on the
available technical solution this data can be exchanged with other Management
Authorities as required.
If a national or regional Single Window is
in place then submitted CITES data will be routed to the Management Authority through
the Single Window and responses from the Management Authority to the trader
will also be routed through the Single Window.
Whichever Single Window is available, the trader and the Management Authority should benefit from lower costs and greater efficiencies.
This chapter presents guidelines on the use
of common information exchange formats, protocols and standards for use with CITES
Some standards are described briefly, but as
it is not within the scope of this toolkit to offer a comprehensive explanation
to all possible standards, references are provided in these cases for accessing
further information if required.
184.108.40.206 WCO SAFE framework
In 2005 166 members of WCO accepted the
Framework of Standards to Secure and Facilitate Global Trade (SAFE Framework). The goal of this instrument is to enforce a closer relationship between international
business and Customs highlighting the security and efficiency aspects in
To achieve the goals set by the WCO
Framework some elements of the framework are considered to be essential.
One aspect of the framework, referring to
the acceleration of electronic trade, is the development of a WCO data model
which will be established to cover all governmental requirements, relevant
trade processes from a customs point of view and also commercial issues
relating to border clearances.
The currently available WCO data model is
version 3.3 which includes a range of data elements and data structures
explicitly defined by WCO covering not only goods import and export declarations,
cargo declarations and conveyance reports but also covering Single Window
governmental agency processes.
This version widens the data model to
include some of the regulatory border release requirements of Partner
Governmental Agencies (PGAs) such as CITES, eTIR, Phyto-Sanitary regulatory
requirements at the border. The WCO Data Model profile, WCO XML schema and
GOVCBR MIG included in the Annexes of this toolkit are based on the WCO Data
Model version 3.3.
220.127.116.11 United Nations/ Centre for Trade Facilitation and Electronic Business and other United Nations projects
The mission statement of the United Nations/
Centre for Trade Facilitation and Electronic Business (UN/CEFACT) is defined as:
“The United Nations, through its Centre for Trade Facilitation and Electronic Business, supports activities dedicated to improving the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively. Its principal focus is on facilitating national and international transactions, through the simplification and harmonisation of processes, procedures and information flows, and so contribute to the growth of global commerce.“
UN/CEFACT is developing a business process model which reflects supply chain processes from an international trade perspective which is known as the ISCRM. The scope of the ISCRM project is to covers commercial, logistics, regulatory and financial processes.
UN/CEFACT BUY-SHIP-PAY (BSP) data model
The UN/CEFACT BSP data model consists of
data structures used across the processes defined in the UN/CEFACT
International Supply Chain Reference Model (ISCRM). These data structures are a
subset of the UN/CEFACT Core Component Library (CCL) which means that they are
compliant with the UN/CEFACT Core Components Technical Specification v2.01 (CCTS)
which is also known as ISO TS15000-5 and ebXML Part 8. The full BSP data model covers
data requirements to support the commercial (BUY), transport and regulatory
(SHIP) and financial (PAY) procedures of cross border trade processes.
The BSP data model is especially in line with the requirements of the cross-border transport sector and therefore covers the core of the CITES regulatory requirements in an international trade environment.
UN/CEFACT BSP data model and its derived components have been chosen as the
basis from which to derive the subset CITES Standard e-Permit data model structure
which will be introduced as an implementable solution in the CITES reference
data model chapter of this toolkit. The CITES data model subset is therefore reusing
the naming and data structure of an already existing sophisticated library
which is approved as a UN/CEFACT Business Standard.
Because this data model conforms to the
UN/CEFACT Core Component Library (CCL) and is based on the Core Components
Technical Specification (CCTS), it is well placed to support future Single
Window approaches and is extendable to fulfil future needs through submissions
to the UN/CEFACT CCL Management Group (TBG17).
UN/CEFACT Core Components Technical Specification (CCTS)
CCTS provides rules for the definition of context
neutral and context specific information in reusable building blocks which are
called core components. UN/CEFACT has developed a library of CCTS core
components covering the international supply chain (B2B, B2G and G2G) and this
library is maintained and published by UN/CEFACT. It is called the UN/CEFACT
Core Component Library (CCL) and it is available from the UN/CEFACT website free
The UN/CEFACT BSP Data Model is based on
the UN/CEFACT Core Component Library.
UN/CEFACT has defined a set of naming and
design rules which are based on the W3C schema definition language (XSD) and
can be used to express Core Component message assemblies as XML schemas. The specification
of the UN/CEFACT XML Naming and Design Rules (NDR) Technical Specification can
be downloaded from the UN/CEFACT website.
To be conformant to UN/CEFACT XML, the XML Schemas must follow the UN/CEFACT XML NDR.
UN/CEFACT has published a set of trade
facilitation recommendations which are available free of charge from the
UN/CEFACT website. For example, there are recommendation on code lists
including ISO Country and Currency code lists, the UNLOCODE, INCOTERMS, Package
Type codes etc. together with recommendations on how to use them.
Recommendation 1 describes how to align the layout of trade documents to the UN Layout Key (see also below) which is followed by thousands of paper forms related to cross-border trading worldwide. Recommendation 33 describes how to prepare for a Single Window approach.
Unite Nations Layout Key
As one of
the first recommendations made by UNECE in 1973, the United Nations Layout Key
for trade documents (UNLK) still plays a very important role for facilitating
international trade. The main function of the UNLK is to present a standard and
universal design for any paper document which can be exchanged by parties in
the international supply chain. The UNLK is a joint standard developed with
ISO where it is referred to as ISO 6422.
Because of the broad acceptance of this
recommendation thousands of documents have been aligned to the UNLK and time
and costs of document processing have over the years been decreased for many
administrative processes significantly.
ISO is currently considering to adopt a new work item to develop an equivalent standard for electronic international trade documents to be called the eUNLK or ISO 6422 Part 2.
United Nations Trade Data Elements Directory
The United Nations Trade Data Elements Directory (UNTDED) offers a standard list for trade elements which can be used for data exchange in international trade. UNTDED version 2005 is another joint standard with ISO which is known as the official ISO Standard ISO7372.
A key factor in the development of a migration strategy and its implementation plan is that they must always start from the existing as-is situation. This means that one of the dependencies will be the minimisation of any negative impacts on existing system structures and the current data exchange techniques during the implementation stages.
Below are some general issues, which may be
considered when drafting a project plan for implementation:
To gain a concise
picture of the current (as-is) situation, implemented systems, their processes
and compatibilities should be analysed. This exercise should include aspects of
technologies used and security and business issues. This collated information
about the current situation will assist to identify strengths, weaknesses and
requirements for improvements in any future solutions.
Which of the
three general types of permit systems does/will exist?
What can be
improved and which possible improvements depend on implementing new
security issues have to be considered?
§ Basic security:
Confidentiality, integrity, authenticity and availability
§ Document security:
Electronic data exchange employing encryption techniques, (XML)
digital signatures, electronic certificates and certification authorities
§ Application security:
User access controls (Registration with username and password, Smart
§ Data Transfer:
Electronic protocols and digital security mechanisms (https, SSL),
Developing a migration strategy leading
from the as-is to the to-be situation requires the determination of several factors
which will potentially influence the process of implementation. These variable
factors can be fixed in a project plan and some of them are listed below:
What will be the quantifiable and qualitative benefits?
These may include items such as:
Below is a selective list of Parties which
have implemented CITES e-permitting systems. Owing to the difficulty in keeping
this list up-to-date, it will be moved to a Web-based systems where Parties are
able to submit information related to their e-permtting systems. Below are
examples of selected countries:
CITES Management Authority
Single Window Solution
(G2G or Cites2Cites)
Status tracking and data management
Business data input
(E-form, Web app.)
Static Forms (Print)
Automatically (e.g. Web service)
Ministry of Ecology
Agri-Food and Veterinary Authority (AVA)
Ministry of Environment and Water
Management Authority for Abu Dhabi Emirate:
Management Authority for the Northern Emirates:
National Park, Wildlife and Plant Conservation Department
Ministry of External Relations / IBAMA
Ministero dell'Ambiente e della Tutela del Territorio e del Mare
de Industria, Turismo y Comercio
Canadian Wildlife Service
See also: A Survey of Single Window Implementation. World Customs Organization, 2011 (WCO Research Paper No. 17). See: http://www.wcoomd.org/~/media/WCO/Public/Global/PDF/Topics/Research/Research%20Paper%20Series/17_SW_Survey%20Analysis_Choi_EN.ashx?db=web
The UNECE has developed a Single Window
Trade Facilitation Recommendation (UN Recommendation 33) which includes the
“Within the context of this Recommendation, a Single Window is defined as a facility that allows parties involved in trade and transport to lodge standardized information and documents with a single entry point to fulfil all import, export, and transit-related regulatory requirements. If information is electronic, then individual data elements should only be submitted once”.
The WCO has further refined the UNECE definition as follows:
“A Single Window Environment is a cross border, ‘intelligent’, facility that allows parties involved in trade and transport to lodge standardized information, mainly electronic, with a single entry point to fulfil all import, export and transit related regulatory requirements.”
An International Trade Single Window
environment is designed to increase efficiency for traders and governmental
agencies alike for all activities around import/export clearance procedures
including permits and certificates. Users are provided with a single,
coordinated interface to many different government agencies. Required data will
be automatically and electronically exchanged between all market partners and
government bodies through one interface. The primary objective
is that each element of required data should only have to be submitted once
thereby reducing the considerable data redundancy caused by today’s separated
regulatory interfaces and functions.
Additional information on Single Windows and practical steps for their implementation can be found in Recommendation No. 33 of UN/CEFACT (“Recommendation and Guidelines on establishing a Single Window to enhance the efficient exchange of information between trade and government”).
Window concept describes how a Single Window can provide improved services to
businesses, increased national or regional competitiveness by offering reductions
in documentary burdens on traders as well as delivering improved coordination and
streamlining of government operations.
networking between Single Windows across the globe offers further increases in
the benefits when complemented by compliance goals and mutual recognition of
secure trading frameworks between countries.
the recognised benefits in speed of data exchange, increased security and
increased process efficiencies of electronic data transfers will be available
to any Single Window environment. As a result further benefits such as the secure
exchange of pre-approval data and permits before physical goods are going to be
transported may be accrued.
18.104.22.168 Single Window initiatives
probably be helpful to have information on current Single Window developments
which can give an orientation about the possibilities of implementation. Such
relevant reference projects would include:
Single Window frameworks such as WCO (Global Customs based),, APEC (Asia-Pacific Economic Cooperation),
ASEAN (Association of Southeast Asian Nations) and, ITAIDE (Information
Technology for Adoption and Intelligent Design for EGovernment)
Country governmental Single Window projects such as those implemented or being implemented in Canada, France, Singapore, United Kingdomof Great Britain and Northern Ireland, and United States of America
CITES Management Authorities wishing to
offer services through a Single Window system should consider
the following steps:
Beneﬁts from a trader perspective
Beneﬁts from a Management Authority perspective
Interoperability is the capacity of
heterogeneous systems to be able to work together.
To establish or improve interoperability between applications and organisations, an understanding of the following conceptual levels of interoperability is useful:
Business Process level
The business process level defines when and why certain data is exchanged between organizations or organizational units. Interoperability is achieved by aligning distinct business processes with one another.
Data Semantic level
This level is related to the content of
the data transmitted. This content is often described as the semantic content
or the meaning of the data. When two systems exchange data, full semantic interoperability
can only be achieved when all of the data exchanged is interpreted in exactly
the same way by both communication partners thereby eliminating
The basic pre-requisites for semantic
interoperability are shared names and definitions for data elements plus
commonly agreed to codes. Whilst bilateral semantic agreements between
individual pairs of trading partners may be simpler to arrange, the wider that
such commonly defined semantics can be adopted across trading communities the
greater semantic interoperability benefits can be achieved.
Global semantic standards in the form of internationally maintained libraries such as the ISO 7372 Trade Data Element Directory, UN/CEFACT Core Component Library (ebXML) and the WCO Data Model are important as they can together provide a trustable and well maintained foundation on which trading communities can build semantic interoperability platforms.
Message Structural level
This level concerns shared data structures
and the relationships between them. When data is exchanged in the form of
electronic messages, it is important that the exchanged data follows a
pre-defined structure so that the receiver can understand the relationships
between the pieces of data received.
Message structures are developed as
representations of data models can be: a) bilaterally agreed, b) community
agreed such as GS1 EANCOM messages, or c) globally standardised such as the
UN/EDIFACT (United Nations/Electronic Data Interchange For Administration,
Commerce and Transport) Standard Messages (UNSMs) and UN/CEFACT XML Messages.
Message structures define cardinalities as well as business entity relationships which are linked together to form a message assembly. They can be thought of as a UML class diagram expressed in a chosen message syntax.
specifies the syntax in which electronic document interchanges (EDI) are
conducted and in which the document structures are defined as described above.
The most common EDI syntaxes are XML or UN/EDIFACT. However, in the case of XML
there are several different dialects and the recommended version for
international e-business is the W3C XML Schema Definition Language commonly
referred to as XML schemas.
The syntax level consists of two or three distinct parts: a) the message structure definition, b) instances of actual data exchanges which comply with the message structure, and c) an optional message implementation guideline which defines agreed business rules to be applied to the processing of received instances such as an EDIFACT MIG or an XML Schematron file.
Communication protocol level
This final level defines the handshaking communication protocols which enable two exchange systems to talk successfully with each other in order to exchange electronic information.
The Convention is a legal framework that –
together with its requisite national implementation - lays the ground for business
With regards to the semantic level, the syntax and meaning of electronic CITES documents will need to be carefully described in order to enable cross-border cooperation when using such documents (permits and applications for permits). In this toolkit, this is achieved by the uniform XSD-representations of permits and the concepts involved. Cf. CITES Reference Data Model and CITES XML Schema.
(R1) Use internationally agreed to and established open standards when describing and mapping CITES documents for use in e-permitting systems.
1.7.1 Information security management
The establishment of an information
technology (IT) security system requires the creation of an IT security
management system which must designate, co-ordinate and monitor IT security
related tasks (in conformity with ISO 27001).
In addition, continuous and effective IT
security processes involve the following recurrent actions:
(R2) Establish a management system in conformity with ISO 27001 to designate, co-ordinate and monitor IT security related tasks.
define the security needs related to communication including :
Secure Data Communication comes in two
different forms: a) the network connection between the communication nodes is
private (e.g. using a virtual private network (VPN)), and b), the partners
communicate encrypted and signed documents via an open network (secure
communication via insecure channels).
With regards to CITES, the latter method may
be more suitable. The almost universal membership to the Convention and the
need to use the Internet as the basic communication channel favour the use of
encrypted and digitally signed documents exchanged via the Internet. The security
of CITES processes (application for permits, sending of permits, securing
permits against forgery etc.) must be assured a high priority. The solutions to
achieve interoperability must in no way compromise technical cooperation among
(R3) Identify and use appropriate technologies when communicating via or using open/insecure networks (i.e. the Internet) to ensure confidentiality, integrity and authenticity of the data being exchanged.
Web Service technology is a means to
integrate applications by having them communicate via a network. The
application establishing and offering the service is called the server,
the one accessing or using the service the client.
Web services are accessible over the HTTP
(Hyper-Text Transfer Protocol) protocol. XML is used as the message format as
defined by the Simple Object Access Protocol (SOAP) standard. Machine-readable
description (also accessible via the network) related to the operations of the Web
service consists of the service specified through the Web Services Description
Web Services can be and are being used for
application integration within an organisation. However, as a result of its
capacity to provide interoperability for applications across platforms and
vendor origins, they can be used –across organizations.
By being independent of technology,
operation systems or programming languages, the Web service standards facilitate
the interoperability among different systems and platforms
Both SMTP (Simple Mail Transfer Protocol)
and HTTP are valid application layer protocols used as transport for SOAP. HTTP has gained wide acceptance as it works well with today's Internet infrastructure,
specifically, with network firewalls (SOAP may also be used over HTTPS, which
is the same protocol as HTTP, but uses an encrypted transport protocol
XML (Extensible Mark-up Language) should
serve as the universal and primary standard for exchanging data between information
systems. The data shown to the user can be presented in Extensible Style sheet
Language (XSL), providing much flexibility on the presentation layer.
(R4) Use Web service technology among different systems to exchange CITES-related data.
(R5) Use Web service communication such as., SOAP via HTTP / HTTPS),or, where appropriate,. SOAP via SMTP (E-Mail) as an alternative systems .
Currently, Web service technology is used
to access an application by other applications via SOAP to retrieve data
represented as XML documents. In brief, Web service technology offers the best
means to connect applications located in different countries and using
For example, a SOAP message could be sent
to a Web service enabled website (e.g. a job opportunity database) with the
parameters needed for a search. The site would then return an XML-formatted
document with the resulting data (companies, jobs, features, etc). Since the
data is returned in a standardized machine-parseable format, it can then be
integrated directly into a third-party site.
When applied to CITES processes, Web
service technology may be suitable to
(R6) Use Web services to facilitate exchange of CITES-permit data between applications (coupling)..
WS-Security is an OASIS standard for secure Web services. It
defines upgrades of the SOAP protocol in order to provide and ensure
confidentiality, integrity and the binding effect of SOAP messages for securing
Web services. WS-Security supports the signing and encryption of SOAP messages based on XML Signature and XML Encryption. The use of different
security models and different cryptographic method must be possible.
WS-Security also enables different
"security tokens", i.e. data formats which warrant specific
identities or properties, e.g. X.509 certificates, Kerberos Tickets, SAML
tokens or encrypted keys.
The specification of WS-Security consists
of the "WS-Security Core Specification 1.1" and certain profiles that
specify how a certain kind of the tokens mentioned can be used in SOAP:
(R7) Use Secure Web Services for data communication made through open/insecure networks (i.e., the Internet ).
The standards XML Signature and XML
Encryption are crucial for the secure exchange of XML documents.
The joint W3C and IETF standard XML
Signature (XML Signature Syntax and Processing, W3C Recommendation and IETF
RFC 3275) describes digital signatures for all kinds of data (usually XML) by
providing an XML schema and a set of processing rules for generating and
validating the signature. The signature can cover one or more documents and/or
different kinds of data (pictures, text, etc.).
One central feature of XML Signatures is
that it is possible to sign specific parts of an XML document rather than the
entire document. This flexibility makes it possible to secure the integrity of
certain elements of an XML document whilst other parts can be edited. For
instance, a user can fill in certain parts of a signed XML form without
violating the integrity of the document. This was not possible with
conventional signatures because the complete document was always signed, so
that any change / addition would have meant a violation of its integrity.
The W3C standard XML Encryption (XML
Encryption Syntax and Processing, W3C Recommendation) provides an XML schema
and a set of processing rules which support the encryption / decryption of
entire documents, including XML documents, XML elements and contents of XML
Together with XML Signature, XML Encryption
is the foundation for several standards accepted in the industry for secure
XML-based document exchange.
(R8) Use standards based on XML Digital Signature and XML Encryption when implementing Secure Web services for the exchange of CITES-related information.
The Web Service Interoperability
Organization (WS-I) offers guidance with regard to implementation of Web services.
It comprises a diverse community of companies and standards development
organizations (SDOs) interested in the development and the application of Web
WS-I committees and working groups create
Profiles, Testing Tools and Sample Applications published on the Internet under
an open and public license.
most important WS-I Profiles are:
(R9) Use WS-I profiles as guidelines to implement Web service communication and to ensure interoperability of the resulting service.
CITES relevant data between two CITES Management Authorities can be described
from a business perspective as a single window solution. Technically, the data
exchange processes uses two servers as single points of exchange (SPoX) one on
the import side and one for the exporter.
Source: CITES Data Exchange pilot project
There are some important prerequisites which are necessary to
transfer CITES data via Web service technology:
Electronic signatures are common, proven
and reliable tools to secure contents (e.g. export and import permits) and
This section will describe briefly the technical and organizational requirements that should be taken into consideration in order to secure e-permits by electronic signatures.
"Electronic signature" is a
rather broad term referring to any electronic data that carries the intent of a
signature. Not all electronic signatures use digital signatures.
A digital signature is a type of asymmetric
cryptography involving application of private and public keys by sender and
receiver (or author and reader) to messages or documents. Digital signatures
have the potential to provide for authenticity and integrity (see Protection Aims & Secure Data Communication).
An asymmetric signature method consists of a signing and a verification algorithm. The signature method is dependent on the key pair: the private (i.e. secret) key is used for signing (generating) and the pertinent public key for verifying (checking) the signature.
1.9.2 Application of digital signatures
For messages sent through an insecure
channel, a properly implemented digital signature gives the receiver assurance
that the message was sent by the claimed sender (authenticity) and that
it was sent consisting of exactly the content having been received (integrity).
Digital signatures can also provide the
property of non-repudiation of a message or a document, meaning that the
signer (sender or author) cannot successfully claim he did not sign a message,
while also claiming his private key remains secret.
Digitally signed messages may be anything
representable as a bitstring: examples include electronic mail, contracts, or a
message sent via some other cryptographic protocol.
(R10) Use digital signatures to provide authenticity and integrity when exchanging CITES-related permit information.
In the context of Web services XML Digital Signature and XML Encryption are recommended as the suitable technologies to implement digital signatures applied to data and document communication.
1.9.3 Other issues related to digital signatures
Digital signatures are equivalent to
traditional handwritten signatures in many respects. Properly implemented
digital signatures are more difficult to forge than the handwritten type. In
some countries, electronic signatures – properly applied - have legal
significance as a binding declaration of will.
The legally binding nature of electronic
communications is a crucial success factor for the implementation of e-Government.
Contrary to a simple or advanced electronic signature, a qualified electronic
signature offers the highest degree of electronic replication of a handwritten
The legal adjustments required to enable
the use of electronic signatures and to place these on the same standing as a
hand-written signature depends on the regulations in the respective countries.
In many countries, as a prerequisite for
the legal equivalence of electronic signatures with a handwritten signature,
the private key used in the algorithm to create the signature has to be stored
on a smartcard, connected to the signing computer by a card reader machine
equipped with a key pad of its own.
Smartcards are chip cards with an
integrated processor; they are also referred to as microprocessor cards. In
contrast to chip cards which are used to only save data (memory cards),
smartcards can also process data. Smartcards can serve as a Personal Security
Environment (PSE), in order to safely store trustworthy certificates and keys,
and also as a (secure) signature generation unit.
1.9.4 Algorithms and Security
The security of an electronic signature is
primarily dependent upon the strength of the underlying cryptographic
SHA-256 (Secure Hash Algorithm), as a
further development of SHA-1 (160-bit long hash value), is a cryptographic hash
function that generates a 256-bit long hash value.
SHA-224, SHA-384 und SHA-512 (Secure Hash
Algorithm) are further developments of SHA-1 (160-bit long hash value) and
constitute cryptographic hash functions that generate longer hash values (the
length corresponds to the number stated).
Furthermore, RSA, should be used as the asymmetric
The level of security the mentioned
algorithms provide for is dependent on a given technological context. For any
given period an IT service is operated in there will have to be an assessment
about the adequacy of the chosen Algorithm relative to security requirements.
In conclusion, applications exchanging data
related to CITES permits should use digital signatures to protect against identity
fraud and data manipulation.
(R11) Use RSA as the asymmetric signature method and choose an appropriate algorithm based on recommendations of experts responsible for IT security .
 B2B: Business-to-Business, B2G: Business-to-Government, G2G: Government-to-Government
 Recommendations of UN/CEFACT: http://www.unece.org/cefact/recommendations/rec_index.htm
 Link to recommendation No. 33: http://www.unece.org/cefact/recommendations/rec33/rec33_trd352e.pdf
 ITAIDE aims to integrate and strengthen European research for innovative government by enhancing service offerings and disseminating good governance practice through increased security and controls, while employing intelligent software tools to reduce administrative load burden. ITAIDE addresses the issue of eCustoms: How can customs documents and procedures be digitized and redesigned, and what business and administrative challenges may be encountered?
 OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets.
 RSA algorithm was publicly described in 1978 by Ron Rivest, Adi Shamir, and Leonard Adleman at MIT; the letters RSA are the initials of their surnames.