Registry system data exchangeGeneral design requirements

Pre-sessional Consultations on Registries

19 October 2002

New Delhi, India

UNFCCC secretariat

www.unfccc.int

Geoff Sinclair

Consultant

2

Purpose of this presentation

• Explain approach taken in possible general design requirements in the annex

• Raise some key issues & questions

3

Overall approach to general design requirements

• Not detailed design– Define the ‘what’ before the ‘how’– ‘How’ can be left to technical/IT specialists– Allow flexibility of solutions

• Read with decision 19/CP.7• Concerned with ‘physical’ issuance, transfer

and retirement of units, NOT commercial transactions/contracts or forward trades

4

Structure of Annex 1

I. Purpose

II. Principles

III. Interfaces for data exchange

IV. Requirements of registries and transaction

log for data exchange

5

II. Principles (para 4)

• A guide to technical choices

• Provides guidance for ongoing technical

evolution

• Very high level

6

Principles (current draft)

• Effective facilitation of mechanisms • Accuracy of data and its exchange• Transparency and auditability of transaction

processes• Transparency of non-confidential information• Efficiency in transaction procedures• Security of data and its exchange• Independent design of individual registry

systems

7

III. Interface between registry systems

• Common ‘language’ between registries– Makes data exchange possible

8

Interface between registry systems

What messages and in what sequence?Registry A

Transaction log

Registry B

What needs to happenassociated with message sequence?

(transaction rules)

9

Message sequences for…

• Relating to transactions:– Issuance– Internal transfer (CDM registry pending,

cancellation, retirement)– Registry-registry transfer– Carry-over of units to subsequent C.P.

• ‘Housekeeping’– Reconciliation of data– Connection tests– Transaction log online/offline status

• Message content as per para. 6

10

Message sequences (paras 5-9)

• ‘Grammatical structure’ for registry-registry

communications

• Outline types of message sequences needed,

not exact formulation

• Steers away from stipulating particular

software languages/technologies

11

Transaction rules (paras 10-12)

• Units can’t be subject to 2 operations at once

– Maintain integrity of transfer process

• Must be defined point where transfer final

• Response times not specified at level of general design requirements

– Can be specified later

12

IV. Registry system requirements

What data to be transferred?(number elements)Registry A

Transaction log

Registry B

What infrastructure requirements?•Network topography•Reliability (security, testing, downtime)•Transaction log

13

Number elements (paras 13-15)

• Common basic reference information– Tracking and transparency

• Elements driven by Kyoto Protocol mechanisms– Basic outline of minimum content of serial,

account and transaction numbers specified– Registries can associate more information

with serial number if wanted

14

Number elements - issues

• Serial numbers for ERUs: should they

distinguish between track 1 and track 2?

• Destination party identifier in transaction

number?

15

Topography option 1: peer-to-peer

Registry

Registry

Registry Registry

Transactionlog

Registry

16

Peer-to-peer topography (continued)

• 39 Annex I Parties – 861 connections– 41 copies of every security key, replaced

regularly (every three months depending on policy and level of encryption)

• Increased security risks• Increased risk of message ‘getting lost’• Higher costs

17

Topography option 2: hub

Registry

Registry

Registry Registry

Transactionlog

Registry

18

Hub topography (continued)

• Fewer connections• Lower security risk• Messages less likely to get ‘lost’• Likely lower costs

• Hub does not control content nor timing of messages

19

Security and availability (paras 17-19)

• Security critical ‘network good’– Breach in one part can effect all other parts

• At general requirements level:– Encryption: not readable by others– Authentication: uniquely identified**– Non-repudiation: single full and final record– Integrity: data not modified– Auditability: full audit trail

• Secure data management within registry systems• Minimum downtime

20

**Authentication: registry or individual?

• Important issue for ongoing design• Could require either:

– Organisation/registry to be identified; or– Individual using that system to be identified

• Individual identification higher cost but lower risk

• Some countries require individual authentication for actions to have legal effect of a signature

21

Transaction log information (para 21)

• Outlines what information transaction log

must collect to do checks

• Could be addressed in general requirements

OR transaction log specification

22

Summary: Issues to address now

• Are the principles appropriately worded and comprehensive?

• Serial numbers: differentiate ERU track 1 vs 2?• Transaction numbers: include destination party

identifier?• Peer-to-peer or hub network topology?• Individual or corporate authentication?• Information required by transaction log: here or

in TL specification?