Registry system data exchange General design requirements Pre-sessional Consultations on Registries 19 October 2002 New Delhi, India UNFCCC secretariat 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 happen associated 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 Transaction log 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 Transaction log 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?