Date post: | 13-Dec-2015 |
Category: |
Documents |
Upload: | caden-goodchild |
View: | 216 times |
Download: | 2 times |
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?
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
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?