Upload
paulina-walker
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
Data Exchange Standards in support of transaction processes
08 November 2004Bonn, Germany
Peggy Quarles
Perrin Quarles Associates, Inc.
What is the purpose of the DES?
• Define secure communication mechanism
• Coordinate registry and ITL actions in transaction and reconciliation processes
• Define data requirements for ITL review of registry transfers and unit block actions
• Standard setting and procedures for technical cooperation
• Ensure consistency with Kyoto rules
• Requirements to ensure robust registries
• Introductions and General Information
• Section 3: Communications and Security
• Section 4: Unit Transactions
• Section 5: Reconciliation
• Section 6: ITL Administrative Processes
• Section 8: Change Management
• Section 9: Registry Testing
How is the DES Organized?
Annexes for Technical Developers
Annex Purpose
A Glossary
B, C, D Guidelines for Developing Technical Components and Functions
E Checks Performed by ITL and Response Codes
F Definition of Identifiers
G List of Codes
H Test Protocols
I, K, L Data Exchange Formats (WSDLs and Examples)
J Checklist of Requirements
How do Registries and the ITL Communicate?
VPN
XML Request“I am proposing a transfer
to another registry.”
XML Request“I have a transfer proposal,
Please confirm or reject.”
XML Response“Proposal is acceptable, I will
log and forward this.”
XML Response“The proposal is acceptable.”
ITL
TransferringRegistry
AcquiringRegistry
What Makes the Exchange Secure?
• Authentication through digital signatures
• Virtual Private Network (VPN)
• Encryption
What are the Communications Standards?
• Web services and the Simple Object Access Protocol (SOAP)
• Virtual Private Network (VPN)
• Extensible Mark-up Language (XML)
Transaction Processes
• A transaction is a unique operation on a unit or block of units.
• A transaction is comprised of a series of actions related to a specific process.
• Each transaction is processed in stages and results in the return of a message to the registry or to the ITL.
Kyoto Protocol Transaction Types
• Issuance: Initial creation of an AAU, RMU, CER, tCER or lCER
• Conversion: Transformation of an AAUs or RMUs into ERUs
• External transfer: To move units from an account in one registry to an account in another
• Cancellation: To move a unit into a cancellation account permanently (can be voluntary, mandatory, or for project-related reasons)
Kyoto Protocol Transaction Types
• Replacement of tCERs and lCERs: To take account of the temporary nature of removals
• Retirement: Internal transfer of units to retirement accounts to meet compliance target
• Carry-over of units to next Commitment Period
• Expiry Date Change: To extend the “life” of a tCER or lCER.
Transaction States• Proposed: Transaction that has been sent to ITL
• Accepted: External transaction approved by ITL and accepted by Acquiring Registry
• Terminated: Transaction invalidated by ITL and ended by Registry
• Finalised: Transaction was validated and completed by Registry
• Cancelled: Transaction that was not responded to within 24 hours
Account Types
• Holding. For units not designated for a specific purpose, and available to be transferred.
• Pending. For units issued by the CDM Registry, prior to their distribution to project participants
• Cancellation. For units no longer available for trading or compliance
• Retirement. For units used for compliance
• Replacement. For units compensating for tCERs and lCERs which expire or otherwise lose their validity
Serial Numbers
Some Unit characteristics cannot change:
• Originating Registry or Party
• Unique identifier
• Original Commitment Period
• Track
• LULUCF Activity Code
• Existing Project Number
More on Serial Numbers
Some Unit characteristics can change, through specific transactions:
• Applicable Commitment Period (through Carry-over)
• Expiry Date (only tCERs and lCERs)
• Unit Type (Conversion of AAUs and RMUs to ERUs)
Unit Blocks
• Start Block and End Block define “Unit Blocks” of serialized units
• Unit Blocks can be “split” within a registry and within the ITL
• A unit is uniquely identified by the registry in which it is created and its unique number (for example, FR100001)
• CDM Registry uses the project host Party instead of the Registry (for example IN100001).
Unique Identifiers
Type Example Rules
Account Number FR1000 Registry Code + unique #, assigned by Registry
Transaction Number
FR1000 Registry Code + unique #, assigned by Registry
Reconciliation Number
FR1000 Registry Code + unique #, assigned by ITL
Project Number BO101 Party Code + unique #, assigned by Executive Board or JI Committee
Notification Number
1001 Unique #, assigned by ITL.
Key Transaction Terms
• Transaction: A series or exchange of messages relating to a single transfer of units
• Message: A communication between the ITL and a registry
• Response: Information sent about a proposed transaction (Transaction ID, response codes, statuses)
Processing
Processing
Processing
Processing
Single Registry Transactions
Initiating Registry ITL
Send Proposal to ITL for validation
Validate Proposal
Is it Okay?
Send result of validation to registry
Send notification to ITL of the update transaction state
Update Transaction Status
Update Status
Generate Proposal
Update Transaction Status
Does registry confirm?
Single Registry Behaviour Diagramand theIssuance Example
:InitiatingRegistry
User Initiates Transaction
:ITL
:Registry User
sd Single Registry Transactions
Registry Checks Transaction
Generate_Proposal()
ITL Validates Proposal
[ Result = Validation Checks Fail ]alt
[ Result = Validation Checks Successful ]
AcceptProposal()
Finalise_Transaction()
AcceptNotification()
Record Transaction as Completed
AcceptNotification()
[ Result = Registry Terminates Issuance ]
Terminate Transaction(see reference diagram)
[ Result = Registry Confirms Issuance ]
ref
Discrepancy Notification(see reference diagram)
ref
altThis section describes the events that follow from the registry terminating the transaction.
This section describes the events that follow from a successful validation.
This section describes the events that follow from the validation checks failing.
This section describes the events that follow from the registry completing the transaction.
Transfer XML Document 1
Transfer XML Document 2
Transfer XML Document 3
Record Transaction as Checked (No Discrepancy)
Registry Web Services and Functions
Name Type Purpose
AcceptNotification Web service
Receives transaction messages from ITL
AcceptProposal Web service
Receives requests for external transfers from ITL
Check_Version; Data_Integrity_Check; Validate_Proposal;
Preliminary_checks
Functions Performs checks for all incoming transactions
Generate_Proposal; Finalise_Proposal
Functions Create and sends transaction; completes successful transfer
Write_to File; Write_to_Message_Log; Write_to_Transaction; Write_to_Transaction_Block; Write_to_Transaction_Status
Functions Logging and Data Updates
What does the Issuance Transaction Look Like?
Consult Annex L for examples.
.
Categories of Checks
Category Purpose
Version and AuthenticationCan the ITL verify the identify of the
submitter?
Message Validity Is the message readable and complete?
Registry ValidityAre the registries involved authorized to
operate?
Transaction Data Integrity Does the data makes sense?
Message Sequences Is the message in the correct order?
General Transaction Checks
Does the message comply with general requirements for transactions?
Transaction-specific ChecksDoes the message comply with Kyoto
requirements for type of transaction?
Transaction-specific Checks for Issuance
Check Numbers Type of Check
5001, 5002, 5003 Checks on who can issue what types of units
5004, 5005, 5006 Checks on the characteristics of the unit blocks to be issued
5007 Have these unit blocks already been issued?
5008, 5009 Would issuing these blocks exceed the allowable number?
5010, 5011, 5012, 5013, 5014, 5015,5016
Are the units and unit characteristics for CDM projects correct?
Completing the Transaction – Discrepancy
• The Registry terminates the transaction, and sends a terminated message to the ITL
• The ITL records the transaction as terminated and the unit blocks proposed are NOT created
• The Registry can correct the error and resend to ITL as new Transaction
Completing the Transaction – No Discrepancy
• The Registry finalizes the transaction, creates the unit blocks in the Registry database, sends a finalized message to the ITL
• The ITL records the transaction as finalized and creates the new Unit Blocks in the ITL database.