Registry system data exchange General design requirements Presessional

Registry system data exchange General design requirements Pre-sessional Consultations on Registries 19 October 2002 New Delhi, India Geoff Sinclair Consultant UNFCCC secretariat www. unfccc. int

Purpose of this presentation • Explain approach taken in possible general design requirements in the annex • Raise some key issues & questions 2

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 3

Structure of Annex 1 I. Purpose II. Principles III. Interfaces for data exchange IV. Requirements of registries and transaction log for data exchange 4

II. Principles (para 4) • A guide to technical choices • Provides guidance for ongoing technical evolution • Very high level 5

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 6

III. Interface between registry systems • Common ‘language’ between registries – Makes data exchange possible 7

Interface between registry systems Registry A What messages and in what sequence? Registry B What needs to happen associated with message sequence? (transaction rules) Transaction log 8

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 9

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 10

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 11

IV. Registry system requirements Registry A What data to be transferred? (number elements) Registry B What infrastructure requirements? • Network topography • Reliability (security, testing, downtime) • Transaction log 12

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 13

Number elements - issues • Serial numbers for ERUs: should they distinguish between track 1 and track 2? • Destination party identifier in transaction number? 14

Topography option 1: peer-to-peer Registry Transaction log Registry 15

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 16

Topography option 2: hub Registry Transaction log Registry 17

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 18

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 19

**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 20

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 21

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? 22