update on the cites permit exchange project - ippc.int · upgrading their cites systems for...

Update on the CITES permit exchange project

Markus PIKART [[email protected]]

Dear Shane,

As I will not be able to attend the next meeting of the ePhyto Steering I give you a short rundown on latest state of the Electronic Permit Information Exchange (EPIX) project.

Current pilot is between Switzerland and France and a Hub developed by UNEP-WCMC. CH and FR are upgrading their CITES systems for electronic message exchange with Customs so the CITES systems receive

information when Permits are used and information on the actual quantities exported.

Both Parties have done technical message exchange test with the Hub provided by UNEP-WCMC. Tests were

only on the technical level, verifying that a message can be sent and received,

We need now do start functional testing to integrate message exchange into the CITES permit workflow in both administrations. As we feel that the Service provider can not contribute much to this work the development for the higher level standards will be lead by the two Parties.

We have already started to draw up a model business process diagram. Once there is a common understanding on the workflow we will map the electronic message exchanges and define the expected status/error codes and message responses.

Building on this we plan to develop templates for standard business scenarios (such as "request latest CITES permit", " Permit used for import" ,.. ) and how the business scenario is orchestrated through the message

exchange.

Based on the experiences we have made so far we have also revisited possible architectures for CITES permit exchange. We think that CITES parties on the long run will have to support multiple architectures including point to point and Hub solutions. Therefore we think that it is important that CITES develops standards and tools that

work for both architectures.

We made a first assessment of the layers of standards we need for permit exchange for Hub and P2P exchanges which is outlined in the attached paper. We think that there is a set of standard which is common both for P2P and for Hub connections. In addition the Hub will need an additional set of standards and recommendations

which relate of service level, security, management, financing etc. of the Hub.

So as we progress with the pilot the overhead costs and complications of a Hub architecture become more visible. As CITES Parties will have to support P2P and Hub exchanges anyhow we are currently revising our approach to

EPIX:

- We aim to put more emphasis on development of common standards and specifications that is needed for

both connection types.

- We think that both P2P and Hub solutions can be efficient for Parties if there is a well supported Onboarding

process. With Onboarding we mean that a new Party joins into EPIX exchange.

Sent: 17 February 2017 05:59

To: Sela, Shane (AGDI)

Cc: Le Mentec, Kenza [[email protected]]

Attachments: 20170217 EPIX concept pap~1.docx (263 KB) ; 20170123 EPIX technical p~1.docx (1 MB)

of 2Update on the CITES permit exchange project

2017-03-03https://legacyhqmail.fao.org/owa/?ae=Item&t=IPM.Note&id=RgAAAAA9awG35xKFTI...

Agenda: 15 Document: PTC/ESG - March 2017 - 15 7 March 2017

- To make onboarding efficient we plan to centrally develop standards, tools and tests scenarios for the Onboarding party. The objective is to ensure that the new Party is compliant to EPIX standards and recommendations, thus avoiding bilateral tests with all exiting Parties/Hubs. - To support onboarding Switzerland may develop an automated test platform were Parties can test the compliance of their systems. - Parties may also needs this platforms if they upgrade their CITES systems/workflow which seems to happen more often than previously thought.

As you can see there is a slight change in the assessment of Hub versus P2P. The main difference is that initially we were not distinguishing between the Onboarding and message distribution function of the Hub. We now think it is better to deal with both aspects separately.

I send you attached for information the latest EPIX technical specification and an outline to assess P2P and Hub architectures and standards. Please note that these papers are a snapshot of current discussions and are not

approved so please limit circulation.

Kind regards, Markus

Mr. Markus Pikart

eMail: [email protected]

Phone: +41 22 9172016

CITES Convention on International Trade in Endangered Species of Wild Fauna and Flora Maison Internationale de l'Environnement

11-13, chemin des Anemones, Office 110

CH-1219 Chatelaine-GenevaSwitzerland

of 2Update on the CITES permit exchange project

2017-03-03https://legacyhqmail.fao.org/owa/?ae=Item&t=IPM.Note&id=RgAAAAA9awG35xKFTI...

SelaS

Highlight

CCCConcept paperoncept paperoncept paperoncept paper on on on on

CITES Electronic permitting Information Exchange (EPIX)CITES Electronic permitting Information Exchange (EPIX)CITES Electronic permitting Information Exchange (EPIX)CITES Electronic permitting Information Exchange (EPIX)

- Discussion paper, not for circulation –

Change history:

20170217 for ePhyto

Summary: This document has been drafted as a discussion paper for the CITES ePermitting

Working Group to aid working group in the development of standards and solutions for

electronic permit information exchange (EPIX) between Parties.

Chapter 1 provides a brief introduction into electronic permitting systems.

Chapter 2 gives a definition of EPIX and its benefits for the Parties.

Chapter 3 introduces in some of the issues related to the dematerialization of permits and

their exchange between Parties.

Chapter 4 discussed Architectures for EPIX exchanges that Parties can implement.

Chapter 5 provides a brief outline of the standards and recommendations that the WG

should develop to provide compatibility of EPIX exchanges.

The text outlined in grey contains recommendations for further work to be conducted by

the WG.

1. Introduction

The eCITES Project implementation framework provides the concept for stepwise

automation of permit processes and electronic information exchange. The concept allows

Parties to adapted eCITES implementation to their needs and readiness.

1. ePermit - Simplified permit issuance: This pillar provides automation mainly between

the CITES Management Authority and the exporters and importers. It automates

business processes related to request of certificates by traders, assessment of risks and

scheduling of inspection, logging of inspection results, issuance of certificate including

electronic records of the certificates and electronic payment of fees.

2. eControl - Border agency collaboration for better controls: This pillar implements

automated procedures between the Management Authority and other control agencies,

thus providing automation on the national level. This includes exchange of permit data

with Customs and other border agencies, use of electronic risk management techniques,

improved data validation and Single Window integration of permits.

3. eExchange – electronic permit exchange with other countries: This pillar implements

automated exchange of electronic permits between CITES trading countries. It

automates business processes for cross border exchange of permits for secure and

integrated management of the trade transaction between the exporting, importing and

transit countries.

4. eReport - automated reporting: This pillar implements automated exchange of data

Management Authority and the CITES Secretariat to meet annual reporting

requirements.

The third step in the eCITES implementation focusses on the exchange of electronic permit

information (EPIX) with other administrations in other countries. The purpose of this paper

is to provide an outline of concepts, standards and best practice that CITES should develop

over the coming years to assist Parties in the implementation of electronic Permit exchange.

2. What is Electronic Permit Information Exchange?

The objective of EPIX is to

• allow safe, secure and reliable exchange of information of Permits between Parties

• reduce costs and effort of Parties for implementing, testing and maintaining

electronic exchanges

• ensure conformity with the provisions of the Convention

• ensure compatibility of solutions system implemented by the Parties for permit

information exchange

• ensure that permit information exchange is compatible with international

standards and complements standards already included in the CITES ePermitting

toolkit.

Definition: Electronic Permit Information Exchange (EPIX) is the exchange of electronic

information related to CITES permits between Government administrations of belonging to

different countries using standards recommended by CITES.

The CITES ePermitting Working Group will develop the EPIX Toolkit (TK) which is a set of

standards, recommendations and compliance tools to support Parties in the

implementation of EPIX.

This definition implies that EPIX is not a software solution. Rather, it is a set of specifications

that should be used by Parties when they implement exchanges.

The EPIX focuses on Permit exchange and is not dealing with annual reporting.

EPIX will focus on Government to Government exchange between Government authorities

of different countries. A Government authority in EPIX context is any authority that has

been designated by the Management Authority (MA) of this country. This can be, for

example the MA itself, the Scientific Authority, the Customs organization or other border

control agencies.

Countries may also use EPIX to implement exchanges between Government agencies of

their own country, for example between the MA and the Customs organization.

The application EPIX by Parties is on a voluntary basis. Parties may establish at any time

exchanges on the basis of their own arrangements.

3. What are the challenges in exchanging electronic information

between countries

This chapter provides a brief background into specific issues that EPIX will have to address.

3.1 EPIX Document workflow

There are fundamental differences in the use of paper and electronic Permits. Information

in an electronic permit can be easily changed using an XML editor while changes in a paper

permit will leave some form of trace. In addition, an electronic permit that has been used

for an export operation cannot be stamped by Customs like a paper permit. Therefore it

could be used many times. To overcome these difficulties the document workflow for

electronic CITES permits is different from the paper Permit workflow.

3.1.1 Document workflow for CITES paper Permits

Figure 1 describes the workflow of a paper permit. The Exporter requests a paper permit

from the MA (Step 1). The MA creates a record in its permit database and issues a paper

permit (Step 2). The exporter sends the paper permit to the Importer (Step 3). The Importer

presents the Permit to Customs and/or to the MA (Step 4).

Figure 1 Cross border document flow of paper permits. Electronic components are marked

in red

3.1.2 Document workflow for electronic CITES Permits

Figure 2 describes the workflow of an electronic permit exchange. The Exporter requests a

permit from the MA (Step 1). The MA creates a record in its permit database and issues a

permit identifier1 (ID) (Step 2). The MA may also print a hardcopy of the electronic permit.

However this copy will be marked as “COPY” and cannot be used for official use. The

exporter sends the permit ID to the Importer (Step 3). The Importer sends the Permit ID to

Customs and/or to the MA (Step 4). Customs/MA send an electronic request for the permit

data to the issuing MA (Step 5). The issuing MA sends an electronic message with the permit

data to the importing country (Step 6).

1 On CITES permits the ID is referred to as the “PERMIT/CERTIFICTAE No.”, printed in box 1

of the permit.

Figure 2 EPIX electronic permit workflow Electronic components are marked in red

This workflow is substantially different from the paper workflow as the permits are now

exchanged between the MAs. The exporter and importer only exchange the Permit ID.

This means that responsibilities for procuring and exchanging the permit and for data

confidentiality now lies with the Authorities in both countries. The authorities are

responsible to the trader for the success of the exchange.

3.2 Inter-Governmental agreements on EPIX

Exchange of electronic CITES permits requires explicit, written agreement between the two

MAs to use electronic permits instead of paper permits for official use. This agreement

could be in form of a MoU. Such an agreement should also specify other relevant aspects of

the EPIX exchange between the two Parties, for example:

• Responsibility of Parties

• Management of the MoU

• EPIX standards used

• Procedures for testing and upgrade

• Retention period of permits

• Sharing of costs

As Parties frequently involve the CITES Secretariat is matters relating to verification of

issued Permits the Parties are encouraged to provide the secretariat with a copy of their

EPIX agreements.

3.3 Signatures in electronic CITES permits

CITES decision Conf. 12.3 (Rev CoP16)2 states that Parties that use electronic Permits need

to use an electronic equivalent for the physical signatures in the Permit.

Different methods exist to implement an electronic signature in a document. UN/CEFACT

Recommendation 14 on authentication of trade documents advises Governments to avoid

over engineering of electronic signature solutions and recommends as best practice that

electronic signatures in a trade document should match the level of security provided by a

physical signature on a paper Permit..

In most administrative systems the electronic equivalent of a physical signature is

implemented by authenticating the user, for example through a username and password.

The system will then log all activities of this user, for example which documents were

approved by the user. This audit trail ensures that the Authority can at any time identify

who signed and approved documents.

3.4 Secure transportation of CITES permits over the Internet

Electronic CITES permits are exchanged through the Internet. The Internet is an open and

anonymous network were anyone can intercept and change messages. Therefore it is

important that EPIX provides rules for secure exchange of CITES permits using a potentially

unsecure transport network.

There are three major security aspects that EPIX TF needs to address:

1) Authentication: messages for permit requests are sent by the computer systems of the

Authorities. This could be the computerised system of the MA, the Customs authority or

the designated Single Window service provider of the Country. In a message exchange

the sending server will identify itself with an internet address which is associated with a

specific administration.

Authentication is a mechanism that verifies that this address is really associated with the

Authority in question. It provides an answer to the question “Is the person that sent me

an email really the person that he/she pretends to be?”

2 https://cites.org/sites/default/files/document/E-Res-12-03R16.pdf

In message exchanges authentication is implemented through certificates3 which are

issued by certification agencies. Numerous private sector companies exist that provide

reliable certificates for the Internet community.

2) Authorization verifies that the Authority that requests a permit is authorized to do so. It

provides an answer to the question “The Ministry of Finance of country XYZ requested a

CITES permit we had issued. Are they authorized to request this permit from us?”.

To manage authentication CITES needs to implement a repository (list) with the to

identify all Authorities that can participate in EPIX exchanges.

3) Security during transport to ensure that no one between the sending and receiving

system can interfere with the EPIX message, i.e. read of change the message content.

The most common transport security standard is Transport Layer Security (TLS) which

implements military grade security for Internet message exchanges through encryption.

Note that computer systems using TLS will encrypt a messages directly before it is sent

and decrypt a message immediately after it is received. If EPIX exchange is implemented

through a Hub the Hub will decode any message it receives. This means that transport

security depends on the security level of the Hub operation which depends on many

different factors. Therefore message exchange using a Hub is potentially unsecure and

requires special attention.

4. EPIX Architectures

There are different concepts to exchange electronic information between countries. These

concepts are often referred to as an “Architecture” as they describe the high level structure

of a system. In the following we describe the two main Architectures that are available to

Parties for an EPIX solution, the Point-to-Point connection and the Hub connection4 and

introduce in the specific issues of the two Architectures.

4.1 Point-to-Point (P2P) Architecture: Direct information exchange between Parties

In a Point-to-Point (P2P) Parties the MAs will directly exchange permits with each other.

They will not use a Hub service provider that interferes in the exchange.

3 See also https://en.wikipedia.org/wiki/Authorization_certificate

4 The Secretariat is currently working with the IBM Research department on a demonstrator for permit

exchange using Blockchain technology. In the future Blockchain might provide an alternative to P2P and Hub

architectures.

P2P Architectures are straight forward to implement and robust. Each Party is responsible

for the security and proper management of their own IT system, in conformance with

national legislation. The communications between the Parties is encrypted using Internet

Transport Security Layer (TLS) throughout which is, for example also used in Internet

Banking. TSL ensures that no one between the Sender and the Received can interfere with

the exchange.

P2P is also a very robust and failure secure system. Each Party is only responsible for the

security of their own system. If one Party is not available, for example because of system

failure this will not affect the communication of the other Parties.

Figure 1 P2P Information flow for electronic permit exchange between 3 MAs

4.2 Hub Architecture: Communication through a central Hub

In a Hub architecture the message exchange between two Management Authorities has

three major components:

- The CITES Permit Repositories (database) of the two Management Authorities

- A Hub hat relays messages between the two Management Authorities

The Hub does not store permits, rather it is a pipeline to transmit information similar to a

postal service. The main role of the Hub is to identify the MA to which the message needs to

be forwarded.

Figure 3 Information flow for electronic permit exchange between two MAs (example):

The Importing country MA requests an electronic permit from Exporting country MA which

has issued the permit. The request is routed through the Hub. The Exporting country MA

selects the permit in its permit database and sends it to the Importing country MA. The

message is routed through the Hub.

From the perspective of the participating Management Authorities the Hub is transparent,

i.e. the permits are exchanged directly between the sending and receiving Authorities. At

any moment there is only one valid and authenticated permit, which is the one that is

stored in the permit database of the issuing MA. By sending a permit request message the

requesting Authority will receive an authenticated copy of this permit.

Hub architectures are significantly more complex to implement and manage than P2P

solutions as the Hub additional system that needs to be integrated, tested and managed and

the Hub itself will require additional software components that need to be developed.

4.3 Hybrid Architectures: Meeting the realities of international trade relations

Most countries have already started to implement exchange Platforms for Government

information such as Singe Window Systems, regional exchange platforms of bilateral

Governmental agreements for Point to Point exchanges.

For example the European Union has already networks for point to Point Customs and

transit exchange and is working on a Hub for agriculture information exchange. ASEAN

Countries have agreed to exchange certificates through a regional Hub while China and

Thailand have established an agreement for but have also established MoU on direct

document exchange. Globally there are numerous new initiatives of Governments to

organise and improve electronic Information exchange between Government agencies

across borders.

When implementing EPIX it is likely that the Management Authority is not free choose its

preferred architecture. Rather it will have to integrate into the overall trade policy and

Information technology strategy of its Government. In this scenario it is also likely that

Parties use different architectures at the same time. i.e. will have direct exchanges with

some parties and exchanges through one or several Huns with other Parties.

As a consequence CITES aims to define the EPIX standards in a way that they are

Architecture neutral and can be used for Parties that are using different architectures at the

same time.

4.4 EPIX Onboarding assessment: Integrating new Parties into an existing EPIX exchange

An important aspect of an Architecture is that it is scalable. For EPIX this meant that new

Parties can join into an existing EPIX data exchange (Onboarding) without putting burden on

the Parties that are already exchanging Permit among each other. In particular a mechanism

is necessary so that the new Party can join without requiring bilateral tests and agreements

between the new Party and each of the existing Parties.

It is suggested that the new Party, prior to joining EPIX is audited for its compliance and

readiness to join EPIX (Onboarding assessment). The Onboarding assessment will assess full

compliance of the Party with the agreed EPIX standards. This ensures that the Party meets

all EPIX standards and makes individual testing with all other Parties obsolete.

The Onboarding assessment is required independent from the architecture that Parties

choose, i.e. it is required both for Point-to-Point and for Hub architectures.

4.5 Comparing CITES Point-to-Point and Hub Solutions

Point-to-Point solutions are simple to implement and robust. They are very easy to scale.

For the Hub solution parties should number of additional points need to be taken into

account:

• The Hub is a potential single point of failure: If the Hub is not operational all Parties

fail to communicate.

• Development and maintenance of the Hub require additional funding, in particular if

high availability of the Hub is required

• Hubs require establishment of management and supervisor function for operation of

the Hub (Service level contracts, cost recovery and of funds, ..)

• The operation of the Hub needs to meet the minimum legal requirements of ALL

Parties. For example, legislation of some countries requires that Government data

can only bestrode on Servers operated under their own jurisdiction. Agreement on a

joint legal, technical can funding framework for the Hub service provider may

require a long negotiation process and in a solution that is still not acceptable to all

CITES Parties.

• When the Hub receives a message it will decode the message and then encode the

message and then encode the message with the key of the receiving Party. This has

to be done with every message sent. This means that during the EPIX exchange the

message is temporarily not encoded and information is potentially subject to

interception or tempering5.

For both architecture solutions it is important that an efficient solution for the Onboarding

assessment is found. CITES needs to establish an audit/assessment process that supports

new parties that want to join into an EPIX exchange to upgrade to EPIX standards and that

can assess and test the compliance of the new Party with regards to EPIX standards. If CITES

does not establish such an Onboarding process the burden of testing will rely on the Parties

themselves.

With regard to Architecture the ePermitting WG should make the following

recommendations:

4.6 Decision matrix to compare options for EPIX exchanges

In this chapter we provide a decision matrix for Parties with list of criteria to compare

different Point to Point or Hub solutions that may be available to them. It is suggested that

Parties add columns on the right side of the table for each option available to them and

then evaluate each option on these criteria.

When making this evaluation Parties should be aware that they need take into account their

specific circumstances, i.e the specific offers that they have received from service providers,

the eBusiness competence of these service provider, funding available to them ect. Also

there may be also additional criteria that are relevant for the Party.

Comparing Point to Point and Hub architectures

Onboarding: Efficiency of EPIX depends very much on the costs/effort to integrate a new

Party into and the EPIX exchange (Onboarding). This requires that CITES provides a

detailed set of EPIX standards. Parties will also need a centrally managed automated test

environment to test their eCITES systems for compliance with EPIX standards. Onboarding

of a new Party will require some assistance from the Secretariat or a competent advisor.

The costs for Onboarding depend on the quality of the standards and tools provided. They

are independent from the architecture.

Tests, debugging and exemption handling: Parties need to test whether their eCITES

systems can handle all situations of real exchanges, including exceptions (lost messages,

systems not responding, ..). Testing of Hub solutions may be more complex as reactions

one additional Party needs to be synchronised.

Software development: The software development costs for making a national eCITES

system EPIX compatible are independent from the architecture choice.

Security (national system): Parties are responsible to take appropriate measures to

ensure security of their national systems. Costs for security of the national system is

independent from architecture decision.

Security (exchange): Point to point exchange between parties is through encrypted

communication (TLS 2.x standards). If properly implemented this communication is highly

secure.

Parties using a Hub need to implement the same security measures as in P2P. In addition

Parties need to audit the security of the Hub Service provider: In exchanges using a Hub

the message is decrypted by the Hub service provider. This creates an important potential

security risk that needs to be addressed.

The costs and effort in a Hub solution to reach the same level of security are considerably

higher than in Point to Point solutions.

Stability of exchange: Stability in point to point exchanges depends on the availability of

the eCITES system of the sending and receiving Parties. Parties need to take appropriate

measures ensure stability of their national systems.

In Hub solutions need to take same measures as in point to point implementations. In

addition the Hub itself is a potential single point of failure. Parties need to take

appropriate measures to ensure availability of the Hub.

The costs and effort in a Hub solution to reach the same level of availability than in Point

to Point solutions are considerably.

Funding for Hub: A Hub solution requires substantive funding for the Hub. Funding

includes development of the Hub solution, operational costs, implementation of adequate

measures for availability, disaster recovers and security and management, operation and

steering of the Hub.

5. Standards and tools for CITES EPIX

5.1 Reference Model for CITES EPIX Standards and tools

This chapter escribes EPIX standards which are required both for EPIX Point to Point and Hub

solutions. If Parties use a Hub solution then the Hub must be compliant in addition with the

standards outlined in 5.2

For EPIX we distinguish 7 layers which describe the layers of EPIX message exchanges and

the standards, tools and recommendations required to support the message exchange:

• Data Model Layer (Layer 0): Standards to encode the CITES Permit in electronic

format including use of codes in permits. This standard has been already developed

and is published as the CITES ePermitting Toolkit V2.06.. Compatibility with this

standard can be checked using the eCITES automated validating tool provided by

GEFEG.

EPIX Data Model standards include:

a) Use of standard data format and structure for electronic permit exchange

Based on CITES ePermitting Toolkit 2.0 data model7, UN/CEFACT CCTS data

mapping

b) Valid CITES XML permit verified through test with GEFEG eCITES XML Permit

AutoCheck8

• Message Exchange Layer (Layer 1): A set of EPIX standard messages that are

exchanged between the Parties. These standards are currently developed and tested

in the pilot project between France and Switzerland.

EPIX Message Exchange standards include:

• Communication Standards

� WebService/SOAP

• Standard Service Calls

6 https://cites.org/eng/prog/e/e-permitting-toolkit.php

7 https://cites.org/eng/prog/e/e-permitting-toolkit.php

8 https://portal3.gefeg.com/ecites/page/about

� GET FINAL

� GET NON FINAL

� CONFIRM QUANTITIES

• Standard Status of ePermits

• A CITES application and permit processed in the national eCITES system may

go through a sequence of status during its lifetime which depend on the

workflow in the MA and national requirements and legislation. When permits

are exchanged with other Parties essential that there is a common

understanding about the Permit status. For EPIX exchanges the following

permit status are allowed:

� VALID

� CANCELLED

� NOT AVAILABLE (any other internal/national status except

VALID/CANCELLED)

• Message Authentication and encryption Layers (Layer 2): Authentication and security

in the message exchanges (transport layer) between the IT systems of the

Government agencies that send and receive the permit. This layer includes

o Authentication of the sending and receiving server and encryption, i.e.

ensuring that the sending and receiving system really belongs to the

Government administrations and that the message is encrypted throughout

the interchange.

This can be achieved by using Transport Layer Security (TLS), the standard

security mechanism of the Internet.

However, the WG should specify general EPIX best practice for Transport

Authentication Message layer. For example, the WG should decide whether

Hub Service providers are authorized to decrypt and stored the information

that is exchanged between the Parties.

EPIX Message Authentication and encryption standards include:

o Security Standards

� Need of a TOKEN together with ePermits

� Authentication Mechanisms

� Encryption and Cryptographic Mechanisms

The WG should recommend TLS for exchange of Permits.

The WG should specify the best practice for security and authentication of EPIX

message exchange in collaboration with the legal unit of the Secretariat.

• Party Authentication Layer (Layer 3): Standards and mechanisms to authenticate the

Parties authorized to participate in an EPIX message exchange. This layer essentially

addresses the organization of an efficient Onboarding mechanism that ensures that

only qualified parties can join an EPIX exchange.

• Permit Authentication Layer (Layer 4): A CITES permit contains signatures and seals

to identify the issuing MA, Custom officers and the requester of a Permit. The

convention requires that an electronic Permit contains the electronic equivalent of

these signatures and seals.

Business Process Layer (Layer 5): Collaboration between two MAs through

electronic exchange requires that both MAs have a clear understanding how their

CITES permit processes work and how the exchanged messages fit into this

workflow.

• Government Layer (Layer 6): A CITES permit is a legal, official trade document.

Official exchange of this document between two government agencies of different

states touches upon legal and policy relevant issues. For example,

o Certain jurisdictions require minimum retention policies for official

documents, so agreements need to be in place that the issuing MA can

procure the electronic document during the whole period.

o If goods arrive but the issuing MA is not capable to submit the Permits, for

example because of technical failure of their own servers or of the Hub, the

MA may become liable. The agreement should specify the liability issues.

Electronic exchanges between Government agencies of different countries

typically require that both Governments sign a Memorandum of Understanding

(MoU) to specify their reasonability’s. The WG should provide best practice advice

for EPIX G2G MoUs.

The MoU should include agreements on:

o Accept and agree to EPIX Terms of Service

� Acceptance of ePermits etc.

� Acceptance of availability requirements

� Acceptance of Security requirements

o Existence of a national eCITES System

� Ability to process CITES export applications and to issue electronic permits

with a national IT-System (eCITES)

� Ability to make CITES export permits available through a WebService

� Ability of the national eCITES-systems to process (send/receive) the

standard EPIX service calls:

• GET NON-FINAL

• CONFIRM QUANTITIES

• GET FINAL

o Standard Test Suite

� Use of an automated test environment between national system and

the Onboarding test tools

o Standard EPIX Adapter to connect national eCITES system with EPIX ensuring

security, control and logging of incoming and outgoing EPIX exchanges and

management of the connections

5.2 Additional standards required for EPIX exchange using a Hub architecture

Above the standards required for both, the Point-to-Point exchanges and the Hub

exchanges,

The main advantage of the Hub solution is, that the register (list) of connected parties is

maintained centrally. Once a Party has successfully established a connection to the Hub, the

Hub will manage further connections with other Onboarding Parties. Even with a Hub all

Parties need to parametrize their national eCITES system o that Permits of the new Party are

not issued any more in paper but rather sent electronic.

However, a Hub implies significant complications in the exchange because a 3rd Party (the

Hub Service provider) is now involved in the Government to Government exchange of CITES

Permits. As the Hub Service provider is appointed by the Governments involved in the

exchange the Governments are fully responsible and liable for the actions of the Hub Service

Provider.

This means that software development, governance, liability and security and availability

agreements for the Hub Service provider need to be defined, agreed and funded upon the

Parties. This means that a complete operational and legal environment regarding the Hub

Service provider needs to be developed. Governments will also be responsible for the

Auditing of the Hub Service provider.

Technical Description

ii

Table of Contents

1 Introduction ................................................................................................................................................. 3

2 Roadmap ....................................................................................................................................................... 4

3 Project overview ....................................................................................................................................... 776

4 EPIX and the business flow of CITES .................................................................................................. 10109

5 Proposed Architecture for an electronic Permit Information Exchange system .......................... 141413

6 Data exchange specification ............................................................................................................... 171716

7 Web Service calls ................................................................................................................................. 181817

8 Online portal ........................................................................................................................................ 313127

9 Glossary of Terms .............................................................................................................................. 323229

3468121517221 .......................................................................................................................... Introduction

3

2 Roadmap ....................................................................................................................................................... 4

3 Project overview ........................................................................................................................................... 6

4 EPIX and the business flow of CITES ......................................................................................................... 8

5 ProposedArchitecture ................................................................................................................................ 12

6 Integration with existing e-permitting systems....................................................................................... 15

7 Data exchange specification ..................................................................................................................... 23

8 Glossary of Terms ...................................................................................................................................... 24

3

1 Introduction This Project Description Document provides an overview of the current phase of development of the

UNEP-WCMC implementation of an electronic Permit Information Exchange (EPIX), including

proposed design and technical specifications, in order to promote a shared understanding of the scope

of the system currently being developed. The proposed technical specifications for the system are

provided as a starting point for discussions with interested CITES Parties in order to align the system

with the needs of Parties.

Currently, CITES MAs routinely consult with their counterparts in other countries to verify details on

CITES permits (including permit identifiers) in order to reduce the risk of fraudulent permits being

used. Conducting these consultations by telephone or e-mail can be burdensome for CITES MAs

(particularly those issuing large numbers of permits) and may result in delays and inefficiencies. In the

absence of an automated means for verifying permits, there is also a higher risk of laundering.

An EPIX system provides an automated mechanism for accessing and exchanging permit information

through the establishment of data exchange links between Parties. Each Party will only need to

implement a single connection to EPIX, through which data exchanges with any number of other

Parties can be managed. Authorised users within each country, either Customs or CITES MAs, will be

able to use the online portal to verify details of a permit. We would welcome further input and feedback

from Parties before these are finalised.

1.1 Revision history Version Date Author Comment

0.1 01.09.2016 WCMC

0.2 09.11.2016 WCMC Trade reporting

specification removed.

Update of permit

exchange specification.

0.3 Markus Pikart, WCMC Added description of

online portal

functionality and more

details on permit

exchange: status codes,

error codes, envelope,

request / response

templates

4

2 Roadmap The electronic exchange of CITES permits between Government agencies in international trade transactions will require four components:

• Parties have implemented a national electronic CITES permitting system that automates the issuance of CITES permits and provides an online database containing all CITES permits

• A technical solution for exchange of electronic permits: A pilot for such a technical solution is currently being developed under the UNEP-WCMC Electronic Permit Information eXchange (EPIX) project and described in this document.

• An agreed governance structure for the cross border exchange of CITES permits. The governance needs to address in particular the responsibility of Parties with regard to data accuracy and confidentiality and reliability of services. This Governance structure is expected to be developed under the CITES e-permitting Working Group.

• Capacity building and advisory services for those CITES Management Authorities (MAs) that require assistance to implement the governance structure and the technical solutions.

This document focuses on developing and testing a technical solution. It is fully recognised that the Governance structure must be developed before Parties can use the technical solution for cross border exchange of permit information and before using this information as basis for CITES regulation in their countries.

For example, it needs to be clarified at which moment national MAs need to be able to provide permit information to other MAs, who will have access to the information and at which moment in the trade transaction and who is responsible for the correctness of the data. Parties also need to decide how the EPIX system will be managed and maintained in future, and provide clarity over the fact that use of the system will be voluntary. CITES Parties are encouraged to consider governance questions for discussion at CoP17 and beyond.

Parties should also be aware that prior to exchange of electronic CITES permits both the sending and the receiving country need to implement a national eCITES project to streamline and automate the processes related to CITES permits. Such project will ideally include automation of the request of the trader to the MA to issue a permit, the scheduling of inspection and logging of the results in a database, the issuance of the paper and electronic permit, the payment of fees and the exchange of the electronic permit with the national Customs organization for improved CITES border control.

To participate in cross border exchange of electronic CITES permits using an EPIX the national eCITES systems must be capable as a minimum to store permit data in an electronic format, to exchange electronic permit information with Customs and to

5

expose electronic permit information through an appropriate web service with the EPIX.

Management Authorities that are that are interested to implement national eCITES projects are invited to contact the CITES Secretariat for further information and support.

6

Figure 1: Roadmap to develop the technical and governance components for cross border CITES permit exchange

7

3 Project overview 3.1 Project Goal The overall goal of the development of the UNEP-WCMC EPIX is to reduce incidences of illegal wildlife

trade by enabling CITES Parties to detect fraudulent permits, and to improve the management and

monitoring of legal international trade in wildlife. This will be achieved by developing a system for

CITES Parties to verify and validate CITES permits through a centralised system. The development of

EPIX will also have additional benefits to governments by increasing the efficiency of the permitting

business.

3.2 Project Objectives • CITES Management Authorities are able to securely share permit information with their

counterparts in other countries in order to verify the validity of permits, detect fraudulent

permits and facilitate efficient permitting procedures between trading partners. The system will

enable participating Parties that have electronic means of storing CITES information to

exchange this information and verify the content of either paper permits or e-permits.

• CITES Management Authorities are able to submit CITES trade data to the CITES Trade

Database in a semi-automatic, online manner.

3.3 Project Scope

3.3.1 Activities 1. Scoping/ Stakeholder consultation: Technical discussions with CITES Authorities to assess

Party needs and fine-tune specifications.

2. Develop an EPIX pilot system:

o Develop an online portal to allow the secure establishment of connections and

management of queries, as well as user-management functionality

o Develop Application Programming Interfaces (APIs) to handle WebService/API calls

and to authenticate queries

o Develop documentation to facilitate the use of the system by Parties

o Implement security mechanisms, including authorisation and access monitoring

o Develop trade reporting functionality

3. Promote the system amongst Parties at various key events, including the CITES CoP17 and

the Viet Nam IWT meeting in November 2016 to raise awareness amongst Parties about the

benefits of the system

In order to maximise the impact of the project, future phases will be required to support Parties to join

EPIX and to use it to its full potential on a long-term basis. This would involve the development of a

Governance structure for operation of the system and access to EPIX, awareness raising, capacity

building and technical support and maintenance beyond the completion of this project.

3.3.2 Outputs 1. An EPIX pilot system with functionality to enable Parties to:

8

a. Exchange permit details with other Parties and to verify permits within trade (EPIX

Connect); and

b. Report trade data online directly to the CITES Trade Database (EPIX Report).

3.4 Key Stakeholders • CITES Parties, including CITES Management Authorities and National Customs organizations

• CITES Secretariat

3.5 Success Criteria 1. Parties will conduct all relevant business processes for CITES permit issuance, control and

approval through exchange of the electronic CITES permit.

2. Participating national CITES MAs will be able to connect to UNEP-WCMC EPIX in order to

reduce time spent answering queries related to permit verification;

3. Waiting times for traders will be reduced, as permit information will be rapidly available to

national MAs at the permitting stage, and to Customs at both the port of exit and subsequent

port of import for verification purposes;

4. Cycle time of trade reporting will be reduced where parties opt in to automated trade reporting.

3.6 Assumptions and Constraints

3.6.1 Assumptions • Participating MAs have the capacity to implement and adapt their E-Permit Web Service in

order to facilitate the integration with EPIX;

• Participating MAs are available to answer queries during integration with EPIX;

• Following consultation on the specification, Parties will develop a set of endpoints as defined in

the specifications for messages exchange (see Recommendation for new web services);

• E-Permit Web Services expose data via encrypted connection and guarded by an authentication

mechanism;

• E-Permit Web Services expose data in a format that is compatible with the CITES Toolkit

Version 2 specification;

• E-Permit Web Services endpoints expose all information required for particular use (e.g. all

fields required in the CITES Trade DB in case of trade reporting);

• There are no network obstructions when connecting from EPIX to E-Permit Web Services;

• E-Permit Web Services are available and respond in reasonable time;

• Participating MAs without a national permit repository can still gain access to EPIX through an

online web portal, though not all services of EPIX will be possible through this method.

3.6.2 Constraints

• EPIX can serve data only as fast as E-Permit Web Services can serve it;

• EPIX cannot serve data from E-Permit Web Services that are temporarily unavailable;

9

• EPIX does not store any data coming from the E-Permit Web Services

10

4 EPIX and the business flow of CITES

The following section aims to describe the proposed vision for how EPIX would integrate within the

CITES business flow.

The sequence diagram below demonstrates, in a simplified way, the sequence of steps required for a

CITES transaction. The parts of the diagram in purple are where the functionality offered by UNEP-

WCMC EPIX is relevant. This diagram is provided for illustrative purposes, but it is recognised that the

actual business process will vary across Parties, i.e. not necessarily all Parties carry out all of those

interactions and not necessarily in the same way. A description of the numbered steps is provided

below the diagram. The diagram shows the workflow for an Appendix I trade transaction (export and

import permit required).

Figure 2 Document and information workflow: Business flow of CITES Paper based CITES permit workflow (black)currently, and electronic CITES permit information exchanges with an indication of where EPIX is relevant (in purple).

11

Detailed steps of the CITES business flow (corresponding to Figure 2)

1. Exporter in Country A applies for an export permit to the CITES MA in Country A;

2. Export permit is granted and the Exporter transmits a copy of it to the Importer in Country B;

3. Importer in Country B applies for an import permit to the CITES MA in Country B, attaching

the export permit from Country A

a. CURRENT: same data as already in the export permit needs to be re-entered again into

the import permit

b. IMPROVEMENT: EPIX allows to fetch details of an existing CITES Permit, which in

this case could be used to pre-populate the import permit using details of the

export permit;

4. CITES MA in Country B checks the validity of the export permit

a. CURRENT: CITES MA might need to make a phone call or send an email to their

counterpart to obtain relevant information to check that a permit is valid


this case could be used to check if the export permit is valid;

5. Goods are shipped and need to be cleared by Customs in Country A

a. CURRENT: Where no connection between Customs and CITES Permit repository is in

place, Customs might need to make a phone call to obtain relevant information


this case could be used to check if the export permit is valid;

6. In some cases there will be a feedback loop from Customs at port of export to MA in export

country, for example to adjust quantities of what has actually been exported;


place, one way of facilitating this is to send physical copies of the export permit to the

CITES MA

b. IMPROVEMENT: EPIX allows updates to the status of a permit, which in this case

could be used to notify the CITES MA that goods went through Customs and update

quantities;

7. Goods cross border and need to be cleared by Customs in Country B


place, Customs might need to make a phone call to obtain relevant information about

the import / export permit


this case could be used to check the export permit (fetched from the export MA)

and potentially import permit as well for Appendix I species (fetched from the

import MA) is valid;

12

8. In some cases there will be a feedback loop from Customs at place of entry to CITES MA in

country of import, for example to adjust quantities of what has actually been imported;


place, one way of facilitating this is to send physical copies of the import permit to the

CITES MA

b. IMPROVEMENT: EPIX allows to update the status of a permit, which in this case could

be used to notify the CITES MA that goods went through Customs and update

quantities;

9. In some cases there will be a feedback loop from CITES MA in country of import to CITES MA

in country of export to confirm trade has occurred;

a. CURRENT: CITES MA might need to make a phone call or send an email to their

counterpart to notify them. Depending on the presence and reliability of this step,

CITES MA who issued the export permit is able to recognise whether a permit has been

used and what the final quantities were, and that affects the precision with which

Parties can later prepare their annual reports for inclusion in the CITES Trade

Database;

b. IMPROVEMENT: EPIX allows to update the status of a permit, which in this case could

be used to notify the CITES MA counterpart.

Please see section on Message flows for examples of message exchanges between EPIX and participating systems.

4.1 Related work

The need to move to solutions that facilitate electronic permit exchange has been acknowledged by

CITES Parties. Similarly, it is on the radar of other global conventions which operate using a similar

licensing model.

The official CITES guideline related to building electronic e-permitting systems and facilitating permit

exchange is the CITES Toolkit Version 2. However, while CITES Toolkit defines in great detail the

mapping of the paper permit to an XML structure, it gives no recommendation as to the flow of

messages that will comprise the full exchange protocol between participating systems.

Therefore, in absence of a guideline, many differing models for permit exchange are being currently

developed or proposed, which are important to recognise in order to review the EPIX specification.

4.1.1 Swiss - French bilateral CITES exchange project

Switzerland and France are currently developing a bilateral exchange project which captures the CITES

business flow in a stateful way. That means the status of a permit is being tracked at various points of

the process, in particular the fact that a permit has been used is recorded. Different web services need

to be used at different points in the process to facilitate allowed transitions between states. Some of

those web services are read-only, whereas some have side effects (meaning they make changes in the

source permit repository).

4.1.2 Czech Republic web service developed as part of initial EPIX prototype

The web service developed by the Czech Republic, which has been integrated with the prototype EPIX

system in 2010, is a read-only web service and the exchange model is stateless. Permits are requested in

batches based on input criteria. Permits are released into the exchange when they have been granted

13

and the notion of permit being used is not reflected in the semantics of the web service. Permits are

available at each stage of the process and subsequently in the same way.

4.1.3 IPPC model of exchange for phytosanitary certificates (ePhyto project)

A specification of exchange of phytosanitary certificates is currently being proposed, which has many

similarities to the exchange required in the CITES process. ePhyto will implement a stateless eSPS

exchange mechanism (no storage of document) using the UN/CEFACT WSDL standard for exchange of

eCERT messages. It comes with a description of web services that need to be implemented, as well as

recommended authentication and encryption mechanisms. Some of the web services are read-only and

some have side-effects, related to changing the status of the certificate.

4.2 Comparison of related work to proposed EPIX specification

Under the current specification EPIX does not record or differentiate the status of the permit, assuming

that permits are present in the Conduit from the moment they are granted and are not removed.

14

5 Proposed Architecture for an electronic Permit Information Exchange system

The message exchange between two Management Authorities uses three major components:

- The CITES Permit Repositories (database) of the Management Authority

- A Hub hat relays messages between the two Management Authorities

- Web Service that connects the Repository of the Management Authority with the Hub

The Hub does not store permits, rather it is a pipeline to transmit information similar to a postal

service. The main role of the Hub is to identify the MA to which the message needs to be forwarded.

Figure X Information flow for electronic permit exchange between two MAs (example): The Importing country MA requests an electronic permit from Exporting country MA which has issued the permit. The request is routed through the Hub. The Exporting country MA selects the permit in its permit database and sends it to the Importing country MA. The message is routed through the Hub.

From the perspective of the participating Management Authorities the Hub is transparent, i.e. the

permits are exchanged directly between the sending and receiving Authorities. At any moment there is

only one valid and authenticated permit, which is the one that is stored in the permit database of the

Issuing authority. By sending a permit request message the requesting Authority will receive an

authenticated copy of this permit.

It should be noted that that in an electronic permit information exchange there is no original Permit in

paper format anymore. Instead the exporter receives a copy of the CITES Permit which contains the

identifier of the permit. This information is sent to the importer which provides the permit ID to the

MA and to the Customs authority.

15

Figure XX Information flow for electronic permit exchange with Exporter and Importer (example): The Exporter has received the permit ID from the MA of the exporting country and sends it to the Importer. The Importer hands the ID to Customs or the MA of the importing country. The Authority in the importing country sends an electronic message with the permit ID to the MA that has issued the permit (Step 5). The issuing MA searches the permit in its database and sends the electronic permit (Step 6). The messages are conveyed through the Hub.

An electronic permit information exchange includes the following components:

• CITES MAs have implemented a repository (database) which contains all issued permits.

• This repository is connected to the Hub through a Web Service

• Parties agree on a mutually recognised mechanism for authentication of signatures and seals in

CITES permits

• Parties agree to adhere on a set of rules and responsibilities for permit exchange (Club

agreement). This agreement includes inter alia a mutually recognised mechanism for

authentication of parties and securing of message exchange, quality of data in CITES permits,

liability, availability and archiving of permits, agreements of use of data and confidentiality.

• All systems (eCITES systems, Hub and Internet connections) are continuously connected and

accessible

The Hub itself provides three layers of services to facilitate electronic exchange between the Parties:

16

- Technical specifications, i.e. Data exchange specificationData exchange

specificationData exchange specificationData Exchange Standards (chapter 6) and Web

Service callsWeb Service Description (chapter 7)1

- Conformance and test tools: Requirements specifications and tools for parties to ensure

readiness for electronic permit exchange

- Technical infrastructure to relay messages between two MAs (Hub server)

Security considerations:

The transmission between the CITES MAs and the Hub uses a secured Internet connection2 . The

sending and receiving systems of the MAs and the Hub will authenticate each other and the sending

system will encrypt the data before the data is sent over the network. Similarly the receiving system will

decrypt the information after it has been received. Thus Permit information, although transmitted

through a public network, cannot be read or changed by changed by an intruder.

However, the Permit information is available in readable format the moment it has been decrypted by

the receiving system. Therefore the Parties need to ensure the operational security of their Permit

database. This also applies for the operational security of the Hub.

1 It is envisaged to standardise these specifications in the CITES ePermitting working group and make them available as a recommends standard for CITES parties when exchanging electronic CITES information. 2 Transport Layer Security (TLS) 1.2

Formatted: Font: Italic



17

6 Data exchange specification 6.1 Data model The CITES ePermitting Toolkit v2

3 proposes two aligned data models to represent CITES permits: the

UN/CEFACT model and the WCO Data Model. For purposes of data exchange between CITES MAs and

Customs, the ePermit subset of the UN/CEFACT data model is recommended.

The use of a data model facilitates mapping of data structures present in national systems to into a

standardised representation of the CITES permit form. It also facilitates extraction of data from the

model.

6.2 Web service architecture The WCO data model comes with recommendations for data exchange format, which is defined in ISO

15000(ebXML.Suite of standards). The recommended data exchange protocol is SOAP (Simple Object

Access Protocol). Those recommendations originally come from the 2009 version 3 of the WCO Data

Model, and were reiterated in the 2013 CITES Toolkit.

6.3 Assumptions about exposed web services .

The part of UNEP-WCMC EPIX that handles connecting to and fetching data from a web service

exposed by a national e-permitting system is called an adapter.

Where E-Permit Web Services do not exist yet, or there is the possibility of expanding existing ones, the

recommendation for new web services (detailed below) should be followed. For those cases a generic

adapter will be developed in EPIX that will require minimal configuration when adding new

connections.

Alternatively, where existing e-permitting systems already expose web services that could be used for

connecting to EPIX, a specialised adapter might be implemented in EPIX to facilitate connecting to this

system.

6.4 Recommendation for new web services Draft recommendation for web services exposing permit information from national e-permitting

systems is provided in chapter Error! Reference source not found.Error! Reference source not

found.Web Service calls below, split by “General web service properties” and “Endpoint methodsWeb

Service description”, discussing the overall properties of the Web Service and the particular expected

functionalities respectively.

Please note this recommendation is based on current knowledge of Parties’ systems, which we will aim

to validate through a survey of preferred integration styles. The outcomes might affect the

recommendation.

3CITES Toolkit V2: https://cites.org/sites/default/files/eng/prog/e/cites_e-toolkit_v2.pdf

18

7 Web Service calls

7.1 General Web Service properties The General Web Service properties provide a set of standards for integrating with EPIX. The Table

below provides our initial assumptions on the requirements, but we would like feedback from Parties as

to whether these will be suitable or whether adjustments may be needed before finalising the standards

and technical specifications of EPIX.

Recommendation

Data model CITES Toolkit v2

Data format XML

Data encoding UTF-8

Architectural style SOAP

Transport protocol HTTP

Encryption & signing TLS 1.2

Authentication Client certificates, e.g.2-way SSL

7.2 Message envelope For purposes of routing messages, they should be wrapped in a message envelope that identifies the

caller and callee. The required fields are as follows:

<Caller>



<IsoCountryCode>XX</IsoCountryCode>



<AgencyCode>01</AgencyCode>



</Caller>

<Callee>



<IsoCountryCode>YY</IsoCountryCode>




<!--

The country code and agency code constitute the identifier of the agency, e.g.

'YY01',

19

which can be referenced against a list maintained by the Secretariat.

-->

</Callee>

<Message>



<ID>YY0120170105114700</ID>



<CertificateType>626</CertificateType>



<CertificateStatus>70</CertificateStatus>



<Other></Other>

</Message>

Please note: While the current version of the system relies on authentication checks to identify the

caller and the country parameter passed with web service calls to identify the callee, for the future

versions information from the envelope will be used in order to handle some of the edge cases you

raised. That identification will rely on the list of agencies maintained by the Secretariat.

7.2.1 Status codes The following status codes are available4:

Code Name Meaning

70 Issued Has been given out.

39 Approved Approval has been given.

40 Withdrawn Item is withdrawn.

4 Export specification (eCert) http://www.unece.org/cefact/rsm/rsm_index.html

20

41 Rejected Item is rejected

44 Replaced Item has been replaced.

7.27.3 Endpoint methods The following Web Service calls, based on the specifications of a bilateral permit exchange pilot

between Switzerland and France, showcase the different calls that will be required to be implemented

in national e-permit repositories in order to fully utilise the data exchange full functionality of EPIX

Connect: data exchange and trade reporting.

For each Web Service call, the signature is provided for both SOAP and REST, and a short description

is provided as well as XML request and response templates. For brevity of the output, the representation

of EPermit schema was omitted. It is well documented in the CITES e-permitting toolkit

documentation. Working request / response samples are also provided to Parties as part of the testing

guide. In future, we may be able to create generic code for these Endpoint methods in order to support

Parties.

This specification is intended for SOAP exchange with WS-Security. The CITES Permit XML is

compatible with version 2 of the CITES Toolkit. As an additional security measure, a security token

must be passed as a parameter. That token is permit-specific and generated by the e-permitting system

that issues the permit.

GetNonFinalCitesCertificate

Signature GetNonFinalCitesCertificate(permit identifier, token, iso code)

Description Accepts a permit identifier and respective security token as parameters and returns

details of a single matched valid permit.

Request template:

<x:Envelope xmlns:x="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:urn="urn:CitesDataExchange">

<x:Header>

<Caller>

<IsoCountryCode>GB</IsoCountryCode>


</Caller>

<Callee>

<IsoCountryCode>CH</IsoCountryCode>


</Callee>

<Message>

<ID>GBXXXXXXXXXXXXXX</ID>


<CertificateStatus></CertificateStatus>

<Other></Other>

</Message>

</x:Header>

<x:Body>

<urn:GetNonFinalCitesCertificate>

<urn:CertificateNumber>XXXXXXXXX</urn:CertificateNumber>

<urn:TokenId>XXXX</urn:TokenId>

<urn:IsoCountryCode>CH</urn:IsoCountryCode>

</urn:GetNonFinalCitesCertificate>

21

</x:Body>

</x:Envelope>

Response template (CITES EPermit schema omitted for brevity):

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

<env:Header/>

<env:Body>

<ns4:GetNonFinalCitesCertificateResponse

xmlns:ns4="urn:CitesDataExchange/v1/"

xmlns:ns3="urn:un:unece:uncefact:data:standard:CITESEPermit:2"

xmlns:ns2="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInform

ationEntity:1">

<CITESEPermit>…</CITESEPermit>

<Composite>false</Composite>

</ns4:GetNonFinalCitesCertificateResponse>

</env:Body>

</env:Envelope>

GetFinalCitesCertificate

Signature GetFinalCitesCertificate(permit identifier, token, iso code)

Description Accepts a permit identifier and respective security token as parameters and returns

details of a single matched valid permit. As a side effect it sets the status of the permit to

USED. Can be called only once.

Request template:



<x:Header>

<Caller>



</Caller>

<Callee>



</Callee>

<Message>




<Other></Other>

</Message>

</x:Header>

<x:Body>

<urn:GetFinalCitesCertificate>

<urn:CertificateNumber>XXXXXXXXX</urn:CertificateNumber>

<urn:TokenId>XXXX</urn:TokenId>


</urn:GetFinalCitesCertificate>

</x:Body>

</x:Envelope>

Response template:

Formatted: French (Switzerland)

Formatted: English (Canada)


22


<env:Header/>

<env:Body>

<ns4:GetFinalCitesCertificateResponse

xmlns:ns4="urn:CitesDataExchange/v1/"



ationEntity:1">

<CITESEPermit>…</CITESEPermit>

<Composite>false</Composite>

</ns4:GetFinalCitesCertificateResponse>

</env:Body>

</env:Envelope>

ConfirmQuantities

Comment: Suggest to send the information in the Permit here and not the “quantities” as a variable in

the Web Service:

1. Can be more than one item in the consignment; the permit has 4 blocks (A to D)� we

would need to have a repeating structure here and identiofy to which line item the

updated quantity refers to. The ePermitting standard has already fields to store the

actual quantities as observed by Customs is in the XML structure

ExaminationTransportEvent

2. Note that updates can also be on the B/L or AWB number if the consignment missed

the departure of the vessel/plane

Signature ConfirmQuantities(permit identifier, token, iso code, quantities)

Description Accepts a permit identifier, respective security token identifier and structure with

quantities by position as parameters and updates final quantities.

Request template



<x:Header>

<Caller>



</Caller>

<Callee>



</Callee>



23

<Message>




<Other></Other>

</Message>

</x:Header>

<x:Body>

<urn:ConfirmQuantities>

<urn:CertificateNumber>?</urn:CertificateNumber>

<urn:TokenId>?</urn:TokenId>


<urn:ConfirmedQuantities>

<urn:CitesPosition>

<urn:ID>A</urn:ID>

<urn:InspectedUnitQuantity>4</urn:InspectedUnitQuantity>

</urn:CitesPosition>

</urn:ConfirmedQuantities>

</urn:ConfirmQuantities>

</x:Body>

</x:Envelope>

Response template

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:v2="urn:CitesDataExchange/v2/">

<soapenv:Header/>

<soapenv:Body>

<v2:ConfirmQuantitiesResponse/>

</soapenv:Body>

</soapenv:Envelope>

ServiceStatus

Signature ServiceStatus(iso code)

Description Can be used to test the availability of the E-Permit Web Service.

Request template:



<x:Header>

<Caller>



</Caller>

<Callee>



</Callee>

<Message>

<ID>GBXXXXXXXXXXXXXX </ID>



<Other></Other>

</Message>

24

</x:Header>

<x:Body>

<urn:ServiceState>


</urn:ServiceState>

</x:Body>

</x:Envelope>

Response template


<env:Header/>

<env:Body>

<ns4:ServiceStateResponse xmlns:ns4="urn:CitesDataExchange/v1/"



ationEntity:1">

<ServiceState>

<ServiceIsAlive>true</ServiceIsAlive>

<ServiceMessage>

<MessageCode>Country</MessageCode>

<MessageValue>Switzerland</MessageValue>

</ServiceMessage>

<ServiceMessage>

<MessageCode>Version</MessageCode>

<MessageValue>1.0</MessageValue>

</ServiceMessage>

</ServiceState>

</ns4:ServiceStateResponse>

</env:Body>

</env:Envelope>

7.3.1 A note about the security token The security token, which is a parameter in all web service calls, gives an additional measure of security

when accessing permit details. Its purpose is to prevent accidentally retrieving or updating the wrong

permit as a result of typing in the incorrect permit number. In order for the operation to succeed, the

security token must match.

A security token is a 4-digit string, which is issued at the same time as the permit. A security token and

a permit number are therefore a pair of identifiers, which both need to be known at all stages of the

workflow where operations on the permit happen.

At this stage it is not clear whether all Parties might want to implement this security measure, therefore

the parameter may be left blank when requests are made against an e-permitting system that does not

support it.

7.3.2 Error codes Error response template:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:v2="urn:CitesDataExchange/v2/"

xmlns:urn="urn:un:unece:uncefact:data:standard:CITESEPermit:2"

xmlns:urn1="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInfor

mationEntity:1">

<soapenv:Header/>

<soapenv:Body>

<env:Fault>



25

<faultcode>env:Server</faultcode>

<faultstring>see in detail</faultstring>

<details>

<ns4:CitesDataExchangeFault xmlns:ns2

="urn:a:unece:UNCEFACT:data:draft:ReusableAggregateBusinessInformationEntit

y: 1" xmlns:ns3 ="urn:a:unece:UNCEFACT:data:draft:CBFShip:1" xmlns:ns4

="urn:CitesDataExchange/v1/">

<ErrorNumber>XXXX</ErrorNumber>

<ErrorMessage>XXXXXXXXXXXXXX </ErrorMessage>

</ns4:CitesDataExchangeFault>

</details>

</env:Fault>

</soapenv:Body>

</soapenv:Envelope>

Error codes:

Error number Error message

1000 CITES not available

1001 CITES already used

1002 Position on CITES not found

1003 InspectedQuantity has wrong UnitCode

7.3.3 Other error conditions

EPIX aims to always return a response when error conditions are encountered. Below are some special

error conditions that may arise.

Timeout

When a national web service takes too long to respond.

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soap:Body>

<soap:Fault

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<faultcode xsi:type="xsd:QName">Server</faultcode>

<faultstring xsi:type="xsd:string">This request took too long

to process...</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Service not available

When a national web service is not available.



<soap:Body>

<soap:Fault



26


<faultstring

xsi:type="xsd:string">Savon::UnknownOperationError</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

7.3.4 Operation not available When a national web service does not implement the requested operation.



<soap:Body>

<soap:Fault



<faultstring

xsi:type="xsd:string">Adapters::OperationNotAvailableException</faultstring

>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Caller not found

When the caller is not identified.



<soap:Body>

<soap:Fault



<faultstring xsi:type="xsd:string">CallerNotFound</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Callee not found

When the callee is not identified.



<soap:Body>

<soap:Fault



<faultstring xsi:type="xsd:string">CalleeNotFound</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Internal error

When EPIX encounters an internal error.



<soap:Body>

<soap:Fault






27


<faultstring xsi:type="xsd:string">Something went

wrong</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

7.37.4 Message flows

7.3.17.4.1 Message flows between CITES MAs

This section explains how the proposed set of endpoint methods might be applied to facilitate message

flows between the importing and exporting CITES MA. The situation illustrated is at the point of goods

being declared for import. Two different scenarios are considered:

1) Message flow with status checks and post-import feedback between MAs

2) Simplified message flow without post-import feedback between MAs


28

Option 1: Message flow with status checks and post-import feedback between MAs

Figure 3. Message flow with status checks and post-import feedback between MAs

The import CITES MA looks up the details of an export permit. They can also check the status of that

permit in the source repository, which will allow them to know if the permit had been used. Following

successful checks, the import MA can now update the status of the export permit in the export MA’s

permit repository, as well as update the quantities. Throughout this process messages pass through

EPIX, which relays requests and responses. When following this kind of exchange, both Parties are able

to keep the respective import / export permits up to date.

It is at this point not clear whether this model will be possible to apply by all Parties. Firstly, it is known

that not all Parties differentiate within their national systems between permits that have been used or

not. Secondly, it is unlikely that all Parties currently implement the feedback loop between the import

and export MA that allows to update the status and quantities of an export permit on operational level.

29

Therefore, for those Parties the status of a permit might not be available or reliable, and the possibility

of reporting trade immediately after it happened might not be readily available.

Therefore, a simplified message flow could be envisaged, facilitated by EPIX: one where Parties use the

data retrieved by getNonFinalCitesPermit() to facilitate cross checking details of the paper permit,

without querying or updating status codes or quantities. In such a scenario the advantage offered by

EPIX would be to assist in manual checks which currently require contacting the other Party directly,

which might not always be possible / reliable using phone or email.

Option 2: Simplified message flow without post-import feedback between MAs

Figure 4. Simplified message flow without post-import feedback between MAs

The two described workflows represent our current understanding of the possible scenarios that might

benefit from EPIX. We need to validate this understanding and review to what extent it is possible to

accommodate for differing needs within EPIX.

7.3.27.4.2 Message flows between CITES MAs and Customs

Message flows between Customs and CITES MAs at the national level may vary considerably between

countries and are assumed to be handled nationally. Therefore, facilitating intra-national message flows

between CITES MAs and Customs is beyond the scope of current EPIX developments, where priority is

given to MA-MA exchange. However, in cases where a connection between Customs and the national

MA system is not in place, Customs may be able to take advantage of the EPIX portal to look up permits

by identifier. The following diagram illustrates the exchange.

30

Figure 5.Message flow between exporting MA and Customs where Customs look up permits via EPIX

A very similar flow, but across a border, can also be envisaged should Customs in the importing country

wish to verify an export permit.

In future, establishing Customs as part of the EPIX exchange could allow for permits to be fed into

Customs risk management systems, thus allowing the identification of illegal trade automatically.

7.47.5 Optional web service call specifications

31

Online portal The online portal allows registered & authorised Parties to look up details of permits. In order to

be a registered user, a Party does not need to be a data provider, i.e. that Party’s national system might not be exchanging information via EPIX.

User management The online portal implements a username / password authentication system. Registration of new users is closed to admins. In order to make the system resilient to staff changes in countries and design a consistent permissions system, an entity called “organisation” was introduced, which allows to group users, making the data related to the organisation independent of individual user records.

An organisation might be one of these types:

CITES Management Authority Customs Authority Other, e.g. CITES Secretariat System administrators, e.g. UNEP-WCMC

Each organisation belongs to a country (CITES Secretariat: Switzerland, UNEP-WCMC: United

Kingdom). Every user in the system belongs to one organisation, and within that organisation may have

admin status. Every Web Service adapter object (which defines properties of an MA's Web Service) also

belongs to one organisation rather than country.

A combination of organisation type and the admin privilege will determine the actions users can carry

out within the system in the following way:

A user that belongs to UNEP-WCMC and has the admin privilege can: create / update / delete organisations create / update / delete Web Service adapter properties for each organisation create / update / delete users for each organisation

A user that belongs to a CITES MA and has the admin privilege can: update their own organisation update their own organisation's Web Service adapter create / update / delete users from their own organisation

A user that belongs to Customs / CITES Secretariat and has the admin privilege can: update their own organisation create / update / delete users from their own organisation

A user that belongs to any organisation and does not have an admin privilege can: update their own user record

Access control of permit information A separate concern are access rights related to accessing other Parties’ permit information. That is

controlled on the level of organisation, allowing the organisation administrator to either issue a blanket

permission for all users of the system, or define a list of permitted Parties.

Formatted: Highlight

32

8 Glossary of Terms CITES MA: CITES Management Authority. In the context of this document it stands for person / people

from the CITES MA in country who access the EPIX online portal to verify permits.

CITES MA technical contact: designated people within CITES MA or collaborating institutions

responsible for the integration and maintenance of the connection to EPIX.

Connected CITES MA: CITES MA, whose E-Permit Web Service has been integrated with EPIX.

Customs: in the context of this document, Customs officers who access the EPIX online portal to verify

permits.

E-Permit Web Service: a Web Service, or API (Application Programming Interface), which exposes

permit information from a national E-Permitting system.

Endpoint: An endpoint of an E-Permit Web Service is an entry point into the service that responds to a

particular type of message. For practical purposes it is one of potentially many operations available from

a Web Service, e.g. permit lookup by identifier.

EPIX online portal: An online portal for access by CITES MAs and Customs, which builds on top of

EPIX to facilitate permit verification and trade reporting.

EPIX Conduit: A core component of EPIX that handles data exchange between national E-Permitting

systems.

EPIX API: part of the EPIX Conduit which exposes permits from all connected CITES MAs in a

standardised format via a single interface.

EPIX Adapter: part of the EPIX Conduit that implements the connection to a particular E-

Permit Web Service.

update on the cites permit exchange project - ippc.int · upgrading their cites systems for...

Documents