< draft-hargreaves-odap-01.txt   draft-hargreaves-odap-02.txt >
Internet Engineering Task Force M. Hargreaves Internet Engineering Task Force M. Hargreaves
Internet-Draft Quant Network Internet-Draft Quant Network
Intended status: Informational T. Hardjono Intended status: Informational T. Hardjono
Expires: May 5, 2021 MIT Expires: November 10, 2021 MIT
November 1, 2020 R. Belchior
Technico Lisboa
May 9, 2021
Open Digital Asset Protocol Open Digital Asset Protocol
draft-hargreaves-odap-01 draft-hargreaves-odap-02
Abstract Abstract
This memo describes the Open Digital Asset Protocol (ODAP). ODAP is This memo describes the Open Digital Asset Protocol (ODAP). ODAP is
an asset transfer protocol that operates between two gateway devices. an asset transfer protocol that operates between two gateway devices.
The protocol includes a description of virtual or digital assets held The protocol includes a description of virtual or digital assets held
on distributed ledgers in an open and interoperable format, a session on distributed ledgers in an open and interoperable format, a session
negotiation part and message passing flows between gateways negotiation part and message passing flows between gateways
connecting disparate distributed ledger technologies (DLTs). connecting disparate distributed ledger technologies (DLTs).
skipping to change at page 1, line 36 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2021. This Internet-Draft will expire on November 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Open Digital Asset Protocol . . . . . . . . . . . . . . . 5 4. The Open Digital Asset Protocol . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. ODAP Model . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. ODAP Model . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Types of APIs . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Types of APIs . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Types of Flows . . . . . . . . . . . . . . . . . . . . . 6 4.4. Types of Flows . . . . . . . . . . . . . . . . . . . . . 6
4.5. Resources and Identifiers . . . . . . . . . . . . . . . . 6 4.5. Resources and Identifiers . . . . . . . . . . . . . . . . 7
4.6. Access Modes . . . . . . . . . . . . . . . . . . . . . . 7 4.6. Access Modes . . . . . . . . . . . . . . . . . . . . . . 7
4.6.1. Direct Mode: Simple Client to Gateway . . . . . . . . 7 4.6.1. Direct Mode: Simple Client to Gateway . . . . . . . . 8
4.6.2. Direct Mode: Client to Multiple Gateway . . . . . . . 8 4.6.2. Direct Mode: Client to Multiple Gateway . . . . . . . 8
4.6.3. Relay Mode: Client-initiated Gateway to Gateway . . . 9 4.6.3. Relay Mode: Client-initiated Gateway to Gateway . . . 9
5. ODAP Message Format, identifiers and Descriptors . . . . . . 10 5. ODAP Message Format, identifiers and Descriptors . . . . . . 10
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. ODAP Message Format . . . . . . . . . . . . . . . . . . . 10 5.2. ODAP Message Format . . . . . . . . . . . . . . . . . . . 10
5.3. Digital Asset Resource Descriptors . . . . . . . . . . . 11 5.3. Digital Asset Resource Descriptors . . . . . . . . . . . 11
5.3.1. Organisation Identifier . . . . . . . . . . . . . . . 11 5.3.1. Organisation Identifier . . . . . . . . . . . . . . . 11
5.3.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 11 5.3.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 12
5.3.3. DLT Identifier . . . . . . . . . . . . . . . . . . . 11 5.3.3. DLT Identifier . . . . . . . . . . . . . . . . . . . 12
5.3.4. Resource . . . . . . . . . . . . . . . . . . . . . . 11 5.3.4. Resource . . . . . . . . . . . . . . . . . . . . . . 12
5.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12 5.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Digital Asset Resource Client Descriptors . . . . . . . . 12 5.4. Digital Asset Resource Client Descriptors . . . . . . . . 12
5.4.1. Organization Identifier . . . . . . . . . . . . . . . 12 5.4.1. Organization Identifier . . . . . . . . . . . . . . . 13
5.4.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 12 5.4.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 13
5.4.3. Organizational Unit . . . . . . . . . . . . . . . . . 12 5.4.3. Organizational Unit . . . . . . . . . . . . . . . . . 13
5.4.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . 13 5.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Gateway Level Access Control . . . . . . . . . . . . . . 13 5.5. Gateway Level Access Control . . . . . . . . . . . . . . 14
5.6. Negotiation of Security Protocols and Parameters . . . . 14 5.6. Negotiation of Security Protocols and Parameters . . . . 14
5.6.1. TLS Established . . . . . . . . . . . . . . . . . . . 14 5.6.1. TLS Established . . . . . . . . . . . . . . . . . . . 14
5.6.2. Client offers supported credential schemes . . . . . 14 5.6.2. Client offers supported credential schemes . . . . . 14
5.6.3. Server selects supported credential scheme . . . . . 14 5.6.3. Server selects supported credential scheme . . . . . 15
5.6.4. Client asserts of proves identity . . . . . . . . . . 14 5.6.4. Client asserts of proves identity . . . . . . . . . . 15
5.6.5. Sequence numbers initialized . . . . . . . . . . . . 14 5.6.5. Sequence numbers initialized . . . . . . . . . . . . 15
5.6.6. Messages can now be exchanged . . . . . . . . . . . . 15 5.6.6. Messages can now be exchanged . . . . . . . . . . . . 15
5.7. Asset Profile Negotiation . . . . . . . . . . . . . . . . 15 5.7. Asset Profile Negotiation . . . . . . . . . . . . . . . . 15
5.8. Application Profile Negotiation . . . . . . . . . . . . . 15 5.8. Application Profile Negotiation . . . . . . . . . . . . . 15
5.9. Digital Asset Resource Discovery . . . . . . . . . . . . 15 5.9. Digital Asset Resource Discovery . . . . . . . . . . . . 16
5.10. Accessing Resources via a DLT Gateway . . . . . . . . . . 16 5.10. Accessing Resources via a DLT Gateway . . . . . . . . . . 16
5.10.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 16 5.10.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.2. WRITE . . . . . . . . . . . . . . . . . . . . . . . 16 5.10.2. WRITE . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.3. INVOKE . . . . . . . . . . . . . . . . . . . . . . . 16 5.10.3. INVOKE . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.4. LOCK . . . . . . . . . . . . . . . . . . . . . . . . 16 5.10.4. LOCK . . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.5. UNLOCK . . . . . . . . . . . . . . . . . . . . . . . 16 5.10.5. UNLOCK . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.6. TRANSFER . . . . . . . . . . . . . . . . . . . . . . 16 5.10.6. TRANSFER . . . . . . . . . . . . . . . . . . . . . . 17
5.10.7. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 16 5.10.7. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 17
5.10.8. DESTROY . . . . . . . . . . . . . . . . . . . . . . 16 5.10.8. DESTROY . . . . . . . . . . . . . . . . . . . . . . 17
5.10.9. READ . . . . . . . . . . . . . . . . . . . . . . . . 17 5.10.9. READ . . . . . . . . . . . . . . . . . . . . . . . . 17
5.10.10. NATIVE_TXN . . . . . . . . . . . . . . . . . . . . . 17 5.10.10. NATIVE_TXN . . . . . . . . . . . . . . . . . . . . . 17
5.11. Response Codes . . . . . . . . . . . . . . . . . . . . . 17 5.11. Response Codes . . . . . . . . . . . . . . . . . . . . . 17
5.12. Backward Compatibility . . . . . . . . . . . . . . . . . 17 5.12. Backward Compatibility . . . . . . . . . . . . . . . . . 18
6. Transfer Initiation Flow (Phase 1) . . . . . . . . . . . . . 17 6. Transfer Initiation Flow (Phase 1) . . . . . . . . . . . . . 18
7. Lock-Evidence Verification Flow (Phase 2) . . . . . . . . . . 17 6.1. Initialization Request Message . . . . . . . . . . . . . 19
7.1. Transfer Commence Request . . . . . . . . . . . . . . . . 18 6.2. Initialization Request Message Response (ACK) . . . . . . 20
7.2. Transfer Commence Response . . . . . . . . . . . . . . . 19 7. Lock-Evidence Verification Flow (Phase 2) . . . . . . . . . . 21
7.3. Evidence Validation Request . . . . . . . . . . . . . . . 19 7.1. Transfer Commence Message . . . . . . . . . . . . . . . . 22
7.4. Evidence Validation Response . . . . . . . . . . . . . . 20 7.2. Transfer Commence Response Message (Ack) . . . . . . . . 23
8. Commitment Establishment Flow (Phase 3) . . . . . . . . . . . 21 7.3. Lock Evidence Message . . . . . . . . . . . . . . . . . . 24
9. Security Consideration . . . . . . . . . . . . . . . . . . . 21 7.4. Lock Evidence Response Message (Ack) . . . . . . . . . . 25
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 21 8. Commitment Establishment Flow (Phase 3) . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Commit Preparation Message . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Commit Preparation Response . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 22 8.3. Commit Final Message . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 8.4. Commit Final Response Message . . . . . . . . . . . . . . 28
8.5. Transfer Complete Message . . . . . . . . . . . . . . . . 29
9. Security Consideration . . . . . . . . . . . . . . . . . . . 30
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
There is a lack of interoperability between individual blockchains, There is a lack of interoperability between individual blockchains,
but also a general difficulty building open DLT networks. Extant but also a general difficulty building open DLT networks. Extant
networks are custom built and relatively closed, usually limited to networks are custom built and relatively closed, usually limited to
networks of a single DLT type. networks of a single DLT type.
This memo proposes at DLT-agnostic protocol in order to allow the This memo proposes at DLT-agnostic protocol in order to allow the
creation of business applications that use and modify multiple DLTs, creation of business applications that use and modify multiple DLTs,
skipping to change at page 10, line 31 skipping to change at page 10, line 51
Messages are JSON format, with protocol specific mandatory fields, Messages are JSON format, with protocol specific mandatory fields,
support for arbitrary authentication and authorization schemes and support for arbitrary authentication and authorization schemes and
support for a free format field for plaintext or encrypted payloads support for a free format field for plaintext or encrypted payloads
directed at the DLT gateway or an underlying DLT. directed at the DLT gateway or an underlying DLT.
JSON format message, mandatory fields are shown below: JSON format message, mandatory fields are shown below:
o Version: ODAP protocol Version (major, minor). o Version: ODAP protocol Version (major, minor).
o Session ID: unique identifier (UUIDv2) representing a session
o Sequence Number: monotonically increasing counter that uniquely
represents a message from a session.
o ODAP Phase: The current ODAP phase.
o Resource URL: Location of Resource to be accessed. o Resource URL: Location of Resource to be accessed.
o Developer URN: Assertion of developer / application identity. o Developer URN: Assertion of developer / application identity.
o Action/Response: GET/POST and arguments (or Response Code) o Action/Response: GET/POST and arguments (or Response Code)
o Credential Profile: Specify type of auth (e.g. SAML, OAuth, o Credential Profile: Specify type of auth (e.g. SAML, OAuth,
X.509) X.509)
o Credential Block: Credential token, certificate, string o Credential Block: Credential token, certificate, string
o Payload Profile: Asset Profile provenance and capabilities o Payload Profile: Asset Profile provenance and capabilities
o Application Profile: Vendor or Application specific profile o Application Profile: Vendor or Application specific profile
o Payload: Payload for POST, responses, and native DLT txns o Payload: Payload for POST, responses, and native DLT txns. The
payload is specific to the current ODAP phase.
o Sequence Number: Sequence Number. o Payload Hash: hash of the current message payload.
o Message signature: Gateway EDCSA signature over the message
Other relevant attributes may exists that need to be captured for
logging purposes. See [ODAP-2PC].
5.3. Digital Asset Resource Descriptors 5.3. Digital Asset Resource Descriptors
Resources are identified by URL [RFC 1738] as described below: Resources are identified by URL [RFC 1738] as described below:
o The type is new: application/odapres o The type is new: application/odapres
o The access protocol is ODAP. o The access protocol is ODAP.
Data included in the URL includes the folowing: Data included in the URL includes the folowing:
skipping to change at page 17, line 35 skipping to change at page 18, line 20
5.12. Backward Compatibility 5.12. Backward Compatibility
It is also possible to send a fully formatted native message to the It is also possible to send a fully formatted native message to the
underlying DLT in the Payload field using the NATIVE_TXN operation, underlying DLT in the Payload field using the NATIVE_TXN operation,
directed to a resource URL. This allows existing DLT native code to directed to a resource URL. This allows existing DLT native code to
be ported to ODAP infrastructures with minimal change. be ported to ODAP infrastructures with minimal change.
6. Transfer Initiation Flow (Phase 1) 6. Transfer Initiation Flow (Phase 1)
TBD. This section describes ODAP initialization phase, where a sender
gateway interacts with a target gateway, proposing a session.
For this, several artifacts need to be validated: asset profile,
asset ownership evidence, identities, and logging-related operations
(log profile, access control profile [ODAP-2PC]).
In this phase, gateways implement the Transfer Initiation Flows
endpoint.
In the following, the sender gateway takes instructions from a client
application, while the recipient gateway may act on behalf of
clients.
The flow follows a request-response model. The sender gateway makes
a request (POST) to the Transfer Initiation endpoint at the recipient
gateway.
Gateways MUST support the use of the HTTP GET and POST methods
defined in RFC 2616 [RFC2616] for the endpoint.
Clients MAY use the HTTP GET or POST methods to send messages in this
phase to the server. If using the HTTP GET method, the request
parameters maybe serialized using URI Query String Serialization.
The client and server may be required to sign certain messages in
order to provide standalone proof (for non-repudiation) independent
of the secure channel between the client and server. This proof
maybe required for audit verifications post-event.
(NOTE: Flows occur over TLS. Nonces are not shown).
6.1. Initialization Request Message
This message is sent from the sender gateway to the recipient
gateway. Note that a client (application) can issue an asset
transfer, that is sent to the gateway and converted into an
Initialization Request Message.
The purpose of this message is for the client to initiate an asset
transfer via its gateway. Depending on the proposal, multiple rounds
of communication between clients and gateways, and between gateways
may happen.
The parameters of this message consists of the following:
o Version: ODAP protocol Version (major, minor).
o Developer URN: Assertion of developer / application identity.
o Credential Profile: Specify type of auth (e.g. SAML, OAuth,
X.509)
o Payload Profile: Asset Profile provenance and capabilities
o Application Profile: Vendor or Application specific profile
o logging_profile REQUIRED: contains the profile regarding the
logging procedure. Default is local store.
o Access_control_profile REQUIRED: the profile regarding the
confidentiality of the log entries being stored. Default is only
the gateway that created the logs can access them.
o Initialization Request Message signature REQUIRED: Gateway EDCSA
signature over the message
o Source_gateway_pubkey REQUIRED: the public key of the gateway
initiating a transfer
o Source_gateway_dlt_system REQUIRED: the ID of the source DLT
o Recipient_gateway_pubkey REQUIRED: the public key of the gateway
involved in a transfer
o Recipient_gateway_dlt_system REQUIRED: the ID of the recipient
gatewayinvolved in a transfer
o Escrow type: faucet, timelock, hashlock, hashtimelock, multi-claim
PC, destroy/burn (escrowed cross-claim).
o Expiry time: when will the escrow expire
o Multiple claims allowed: true/false
o Multiple cancels allowed: true/false
o Permissions: list of identities (addresses/X.509 certificates)
that can perform operations on the escrow
o Origin: along with the source gateway DLT, allows identifying from
where are the funds escrowed/provided
o Destination: along with the recipient gateway DLT, allows
identifying to where are the escrowed funds going
o Subsequent calls: details possible escrow actions
o History: provides an history of the escrow, in case it has
previously been initialized. This includes a list of the
transactions on that escrow (transaction ID) and which action it
performed (ActionCategory), the origin and destination, balance,
current status, and ActionLockSpecificParameters.
The sender gateway makes the following HTTP request using TLS (with
extra line breaks for display purposes only).
Example: TBD.
6.2. Initialization Request Message Response (ACK)
After receiving an Initialization Request Message, the recipient
gateway needs to validate the profiles.
This validation could be performed automatically (using a defined set
of rules), or by requiring approval by a client application.
If one of the profiles is rejected, the recipient gateway constructs
a Initialization Denied Message, stating what was rejected, and
proposing an alternative (if applicable).
Otherwise, if approved, the recipient gateway constructs a
Initialization Request Message Response.
The purpose of this message is for the server to indicate agreement
to proceed with the proposed operations, under the proposed profiles.
This message is sent from the recipient gateway to the sender gateway
in response to a Initialization Request from the sender gateway.
The message must be signed by the server.
The parameters of this message consists of the following:
o Session ID: unique identifier (UUIDv2) representing a session.
o Sequence Number: monotonically increasing counter that uniquely
represents a message from a session.
o ODAP Phase: The current ODAP phase.
o Hash of the Initialization Request Message REQUIRED: the hash of
the proposal.
o Destination: if the recipient gateway calculates the destination
address dynamically.
o Timestamp REQUIRED: timestamp referring to when the Initialization
Request Message was received.
o Processed Timestamp REQUIRED: timestamp referring to when the
Initialization Response Message was constructed.
Example: TBD.
7. Lock-Evidence Verification Flow (Phase 2) 7. Lock-Evidence Verification Flow (Phase 2)
This section describes the conveyance of claims regarding to the This section describes the conveyance of claims regarding to the
status of assets or resources from a sender gateway to a recipient status of assets or resources from a sender gateway to a recipient
gateway. gateway.
In this phase, gateways implement the Lock-Evidence Agreement
endpoint.
In the following, the sender gateway takes the role of the client In the following, the sender gateway takes the role of the client
while the recipient gateway takes the role of the server. while the recipient gateway takes the role of the server.
The client makes a request (POST) to the Transfer Request Endpoint The flow follows a request-response model. The client makes a
(API Type-3) at the server gateway. request (POST) to the Lock-Evidence Agreement endpoint at the server.
Gateways as servers MUST support the use of the HTTP GET and POST Gateways MUST support the use of the HTTP GET and POST methods
methods defined in RFC 2616 [RFC2616] at the Transfer Request defined in RFC 2616 [RFC2616] for the endpoint.
Endpoint and the Evidence Validation Endpoint.
Clients MAY use the HTTP GET or POST methods to send the Transfer Clients MAY use the HTTP GET or POST methods to send messages in this
Commence Request or the Evidence Validation Request to the Recipient phase to the server. If using the HTTP GET method, the request
Server. If using the HTTP GET method, the request parameters maybe parameters maybe serialized using URI Query String Serialization.
serialized using URI Query String Serialization.
The client and server may be required to sign certain messages in The client and server may be required to sign certain messages in
order to provide standalone proof (for non-repudiation) independent order to provide standalone proof (for non-repudiation) independent
of the secure channel between the client and server. This proof of the secure channel between the client and server. This proof
maybe required for audit verifications post-event. maybe required for audit verifications post-event.
(NOTE: nonces are not shown). (NOTE: Flows occur over TLS. Nonces are not shown).
7.1. Transfer Commence Request 7.1. Transfer Commence Message
This message is sent from the client (sender gateway) to the Transfer This message is sent from the client (sender gateway) to the Transfer
Request Endpoint at the server. It signals to the server that the Request Endpoint at the server. It signals to the server that the
client is ready to start the transfer of the digital asset. client is ready to start the transfer of the digital asset.
The message must contain claims related to the information from the The message must contain claims related to the information from the
previous flow (Phase 1). It must be signed by the client (sender previous flow (Phase 1). It must be signed by the client (sender
gateway). gateway).
The parameters of this message consists of the following: The parameters of this message consists of the following:
message_type REQUIRED. MUST be the value o message_type REQUIRED. MUST be the value
urn:ietf:odap:msgtype:transfer-commence-req urn:ietf:odap:msgtype:transfer-commence-msg
originator_pubkey REQUIRED. This is the public key of the asset o originator_pubkey REQUIRED. This is the public key of the asset
owner (originator) in the origin DLT system. owner (originator) in the origin DLT system.
beneficiary_pubkey REQUIRED. This is the public key of the o beneficiary_pubkey REQUIRED. This is the public key of the
beneficiary in the destination DLT system. beneficiary in the destination DLT system.
sender_dlt_system REQUIRED. This is the identifier of the origin DLT o sender_dlt_system REQUIRED. This is the identifier of the origin
system behind the client. DLT system behind the client.
recipient_dlt_system REQUIRED. This is the identifier of the o recipient_dlt_system REQUIRED. This is the identifier of the
destination DLT system behind the server. destination DLT system behind the server.
hash_asset_profile REQUIRED. This is the hash of the asset profile o client_identity_pubkey REQUIRED. The client who sent this
previously agreed upon. message.
asset_unit REQUIRED. This is the unit amount of the asset being o server_identity_pubkey REQUIRED. The server for whom this message
transferred, previously agreed upon. is intended.
client_identity REQUIRED. This is the device identity of the client o hash_asset_profile REQUIRED. This is the hash of the asset
(sender gateway). profile previously agreed upon in Phase 1.
server_identity REQUIRED. This is the device identity of the server o asset_unit OPTIONAL. If applicable this is the unit amount of the
(recipient gateway). asset being transferred, previously agreed upon.
client_transfer_number OPTIONAL. This is the transfer identification o hash_prev_message REQUIRED. The hash of the last message in Phase
number chosen by the client. This number is meaningful only the 1.
client.
7.2. Transfer Commence Response o client_transfer_number OPTIONAL. This is the transfer
identification number chosen by the client. This number is
meaningful only the client.
o client_signature REQUIRED. The digital signature of the client.
For example, the client makes the following HTTP request using TLS
(with extra line breaks for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic awHCaGRSa3F0MzpnWDFmQmF0M2ZG
Content-Type: application/x-www-form-urlencoded
{
"message_type": "urn:ietf:odap:msgtype:transfer-commence-msg",
"originator_pubkey":"zGy89097hkbfgkjvVbNH",
"beneficiary_pubkey": "mBGHJjjuijh67yghb",
"sender_dlt_system": "originDLTsystem",
"recipient_dlt_system":"recipientDLTsystem",
"client_identity_pubkey":"fgH654tgeryuryuy",
"server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334",
"hash_asset_profile":"nbvcwertyhgfdsertyhgf2h3v4bd3v21",
"asset_unit": "ghytredcfvbhfr",
"hash_prev_message":"DRvfrb654vgreDerverv654nhRbvder4",
"client_transfer_number":"ji9876543ewdfgh",
"client_signature":"fdw34567uyhgfer45"
}
Figure 5
7.2. Transfer Commence Response Message (Ack)
The purpose of this message is for the server to indicate agreement
to proceed with the asset transfer.
This message is sent from the server (recipient gateway) to client This message is sent from the server (recipient gateway) to client
(sender gateway) in response to a Transfer Commence Request from the (sender gateway) in response to a Transfer Commence Request from the
client. client.
The message must be signed by the server (recipient gateway). The message must be signed by the server.
The parameters of this message consists of the following: The parameters of this message consists of the following:
message_type REQUIRED. MUST be the value o message_type REQUIRED urn:ietf:odap:msgtype:transfer-commenceack-
urn:ietf:odap:msgtype:transfer-commence-resp msg
client_identity REQUIRED. This is the device identity of the client o client_identity_pubkey REQUIRED. The client for whom this message
(sender gateway). is intended.
server_identity REQUIRED. This is the device identity of the server o server_identity_pubkey REQUIRED. The server who sent this
(recipient gateway). message.
hash_commence_request REQUIRED. This is the hash of the Transfer o hash_commence_request REQUIRED. The hash of previous message.
Commence Request received at the server from the previous message.
client_transfer_number OPTIONAL. This is a replay of the o server_transfer_number OPTIONAL. This is the transfer
client_transfer_number (if present) in the Transfer Commence Request identification number chosen by the server. This number is
received from the client. meaningful only to the server.
server_transfer_number OPTIONAL. This is the transfer identification o server_signature REQUIRED. The digital signature of the server.
number chosen by the server. This number is meaningful only the
server.
7.3. Evidence Validation Request An example of a success response could be as follows:
```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"message_type":"urn:ietf:odap:msgtype:transfer-commenceack-msg",
"client_identity_pubkey":"fgH654tgeryuryuy",
"server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334",
"hash_commence_request":"DRvfrb654vgreDerverv654nhRbvder4",
"server_transfer_number":"ji9876543ewdfgh",
"server_signature":"aaw34567uyhgfer66"
}
```
Figure 6
7.3. Lock Evidence Message
The purpose of this message is for the client (sending gateway) to
deliver the relevant asset-lock (or escrow) evidence to the server
(recipient gateway).
The format of the evidence is dependent on the DLT fronted by the
client and is outside the scope of this specification.
The message must be signed by the client.
This message is used client (sender gateway) to convey lock/escrow This message is used client (sender gateway) to convey lock/escrow
evidence to the server (recipient gateway). evidence to the server (recipient gateway).
This message is sent from the client to the Evidence Validation This message is sent from the client to the Evidence Validation
Endpoint at the server. The server must validate the lock evidence Endpoint at the server. The server must validate the lock evidence
claims in this message. claims in this message.
The message must be signed by the client (sender gateway). The message must be signed by the client (sender gateway).
The parameters of this message consists of the following: The parameters of this message consists of the following:
message_type REQUIRED. MUST be the value o message_type REQUIRED urn:ietf:odap:msgtype:lock-evidence-req-msg
urn:ietf:odap:msgtype:evidence-validate-req
client_identity REQUIRED. This is the device identity of the client o client_identity_pubkey REQUIRED. The client who sent this
(sender gateway). message.
server_identity REQUIRED. This is the device identity of the server o server_identity_pubkey REQUIRED. The server for whom this message
(recipient gateway). is intended.
lock_evidence_claim REQUIRED. This is one or more claims signed by o lock_evidence_claim REQUIRED. The lock or escrow evidence (on the
the client (sender gateway) that the asset in question has been ledger L1 fronted by the client G1).
locked or escrowed and under the control of the client.
lock_claim_format OPTIONAL. o lock_claim_format OPTIONAL. The format of the evidence.
lock_evidence_expiration REQUIRED. This is the duration of the lock o lock_evidence_expiration REQUIRED. The duration of time of lock
or escrow, beyond which the evidence claim becomes stale or invalid. on ledger L1 (after which the lock is released).
hash_commence_response REQUIRED. This is the hash of the Transfer o hash_commence_ack_request REQUIRED. The hash of previous message.
Commence Response received by at the client in the previous message.
client_transfer_number OPTIONAL. o client_transfer_number OPTIONAL. This is the transfer
identification number chosen by the client. This number is
meaningful only to the client.
server_transfer_number OPTIONAL. o client_signature REQUIRED. The digital signature of the client.
7.4. Evidence Validation Response 7.4. Lock Evidence Response Message (Ack)
This message is sent from the server (recipient gateway) to client The purpose of this message is for the server (recipient gateway) to
(sender gateway) in response to Evidence Validation Request from the indicate accaptance of the asset-lock (or escrow) evidence delivered
client. by the client (sending gateway) in the previous message.
The message must be signed by the server (recipient gateway). A The message must be signed by the server.
signed response indicates the server has validated the lock evidence
claims and wishes to proceed with the transfer.
The parameters of this message consists of the following: The parameters of this message consists of the following:
message_type REQUIRED. MUST be the value o message_type REQUIRED urn:ietf:odap:msgtype:lock-evidence-ack-msg
urn:ietf:odap:msgtype:evidence-validate-resp
client_identity REQUIRED. This is the device identity of the client o client_identity_pubkey REQUIRED. The client for whom this message
(sender gateway). is intended.
server_identity REQUIRED. This is the device identity of the server o server_identity_pubkey REQUIRED. The server who sent this
(recipient gateway). message.
hash_evidence_validate_req REQUIRED. This is the hash of the o hash_lockevidence_request REQUIRED. The hash of previous message.
Evidence Validation Request received by at the server in the previous
message.
client_transfer_number OPTIONAL. o server_transfer_number OPTIONAL. This is the transfer
identification number chosen by the server. This number is
meaningful only to the server.
server_transfer_number OPTIONAL. o server_signature REQUIRED. The digital signature of the server.
8. Commitment Establishment Flow (Phase 3) 8. Commitment Establishment Flow (Phase 3)
TBD. This section describes the transfer commitment agreement between the
sender gateway to a recipient gateway.
This phase must be completed within the asset-lock duration time
specificied in the previous lock_evidence_expiration parameter
(message 7.3).
In this phase gateways implement the Transfer Commitment endpoint.
In the following, the sender gateway takes the role of the client
while the recipient gateway takes the role of the server.
The flow follows a request-response model. The client makes a
request (POST) to the Transfer Commitment endpoint at the server.
Gateways MUST support the use of the HTTP GET and POST methods
defined in RFC 2616 [RFC2616] for the endpoint.
Clients MAY use the HTTP GET or POST methods to send messages in this
phase to the server. If using the HTTP GET method, the request
parameters maybe serialized using URI Query String Serialization.
The client and server may be required to sign certain messages in
order to provide standalone proof (for non-repudiation) independent
of the secure channel between the client and server. This proof
maybe required for audit verifications post-event.
(NOTE: Flows occur over TLS. Nonces are not shown).
8.1. Commit Preparation Message
The purpose of this message is for the client to indicate its
readiness to begin the commitment of the transfer.
The message must be signed by the client.
The parameters of this message consists of the following:
o message_type REQUIRED. It MUST be the value
urn:ietf:odap:msgtype:commit-prepare-msg
o client_identity_pubkey REQUIRED. The client who sent this
message.
o server_identity_pubkey REQUIRED. The server for whom this message
is intended.
o hash_lockevidence_ack REQUIRED. The hash of previous message.
o client_transfer_number OPTIONAL. This is the transfer
identification number chosen by the client. This number is
meaningful only the client.
o client_signature REQUIRED. The digital signature of the client.
8.2. Commit Preparation Response
The purpose of this message is for the server to indicate to the
client its readiness to proceed with the commitment finalization
step..
The message must be signed by the server.
The parameters of this message consists of the following:
o message_type REQUIRED. It MUST be the value
urn:ietf:odap:msgtype:commit-prepare-ack-msg
o client_identity_pubkey REQUIRED. The client for whom this message
is intended.
o server_identity_pubkey REQUIRED. The server who sent this
message.
o hash_commitprep REQUIRED. The hash of previous commit preparation
message.
o server_transfer_number OPTIONAL. This is the transfer
identification number chosen by the server. This number is
meaningful only the server.
o server_signature REQUIRED. The digital signature of the server.
8.3. Commit Final Message
The purpose of this message is for the client to indicate to the
server that the client (sender gateway) has completed local
extinguishment of the asset on its DLT (L1), and that now on its part
the server (recipient gateway) must re-generated the asset on its DLT
(L2).
The message must contain claims related to the extinguishment of the
asset by the client. It must be signed by the client.
The parameters of this message consists of the following:
o message_type REQUIRED. It MUST be the value
urn:ietf:odap:msgtype:commit-final-msg
o client_identity_pubkey REQUIRED. The client who sent this
message.
o server_identity_pubkey REQUIRED. The server for whom this message
is intended.
o commit_final_claim REQUIRED. This is one or more claims signed by
the client that the asset in question has been extinguished by the
client in its local DLT.
o commit_final_claim_format OPTIONAL. This is the format of the
claim provided by the client in this message.
o hash_commitprepare_ack REQUIRED. The hash of previous message.
o client_transfer_number OPTIONAL. This is the transfer
identification number chosen by the client. This number is
meaningful only the client.
o client_signature REQUIRED. The digital signature of the client.
8.4. Commit Final Response Message
The purpose of this message is for the server to indicate to the
client that it has completed the asset re-generation at its DLTS
(L2).
The message must contain claims related to the re-generated of the
asset by the server. It must be signed by the server.
The parameters of this message consists of the following:
o message_type REQUIRED. It MUST be the value
urn:ietf:odap:msgtype:commit-final-ack-msg
o client_identity_pubkey REQUIRED. The client for whom this message
is intended..
o server_identity_pubkey REQUIRED. The server who sent this
message.
o commit_acknowledgement_claim REQUIRED. This is one or more claims
signed by the server that the asset in question has been
regenerated by the server in its local DLT.
o commit_acknowledgement_claim_format OPTIONAL. This is the format
of the claim provided by the server in this message.
o hash_commitfinal REQUIRED. The hash of previous commit final
message.
o server_transfer_number OPTIONAL. This is the transfer
identification number chosen by the server. This number is
meaningful only the server.
o server_signature REQUIRED. The digital signature of the server.
8.5. Transfer Complete Message
The purpose of this message is for the client to indicate to the
server that the asset transer has been completed and that no further
messages are to be expected from the client in regards to this
transfer instance.
The message closes the first message of Phase 2 (Transfer Commence
Message). It must be signed by the client.
The parameters of this message consists of the following:
o message_type REQUIRED. It MUST be the value
urn:ietf:odap:msgtype:commit-transfer-complete-msg
o client_identity_pubkey REQUIRED. The client who sent this
message.
o server_identity_pubkey REQUIRED. The server for whom this message
is intended.
o hash_commit_final_ack REQUIRED. The hash of previous message.
o hash_transfer_commence REQUIRED. The hash of the Transfer
Commence message at the start of Phase 2 (see section 7.1).
o client_transfer_number OPTIONAL. This is the transfer
identification number chosen by the client. This number is
meaningful only the client.
o client_signature REQUIRED. The digital signature of the client..
9. Security Consideration 9. Security Consideration
Although the current interoperability architecture for blockchain Although the current interoperability architecture for blockchain
gateways assumes the externalization of the value of assets, as a gateways assumes the externalization of the value of assets, as a
blockchain system holds an increasing number of virtual assets it blockchain system holds an increasing number of virtual assets it
becomes attractive to attackers seeking to obtain cryptographic keys becomes attractive to attackers seeking to obtain cryptographic keys
of its nodes and its end-users. of its nodes and its end-users.
Gateway nodes are of particular interest to attackers because they Gateway nodes are of particular interest to attackers because they
skipping to change at page 22, line 22 skipping to change at page 31, line 17
November 1997, <https://www.rfc-editor.org/info/rfc2234>. November 1997, <https://www.rfc-editor.org/info/rfc2234>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
11.2. Informative References 11.2. Informative References
[Arch] Hardjono, T., Hargreaves, M., and N. Smith, "An [Arch] Hardjono, T., Hargreaves, M., and N. Smith, "An
Interoperability Architecture for Blockchain Gateways. Interoperability Architecture for Blockchain Gateways.
draft-hardjono-blockchain-interop-arch-01", October 2020, draft-hardjono-blockchain-interop-arch-02", April 2021,
<https://www.ietf.org/archive/id/draft-hardjono- <https://datatracker.ietf.org/doc/draft-hardjono-
blockchain-interop-arch-01.txt>. blockchain-interop-arch/>.
[HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted
Computing Base for Blockchain Infrastructure Security, Computing Base for Blockchain Infrastructure Security,
Frontiers Journal, Sepcial Issue on Blockchain Technology, Frontiers Journal, Sepcial Issue on Blockchain Technology,
Vol. 2, No. 24", December 2019, Vol. 2, No. 24", December 2019,
<https://doi.org/10.3389/fbloc.2019.00024>. <https://doi.org/10.3389/fbloc.2019.00024>.
[NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
Blockchain Technology Overview (NISTR-8202)", October Blockchain Technology Overview (NISTR-8202)", October
2018, <https://doi.org/10.6028/NIST.IR.8202>. 2018, <https://doi.org/10.6028/NIST.IR.8202>.
[ODAP-2PC]
Belchior, R., Correia, M., and T. Hardjono, "Gateway Crash
Recovery Mechanism. draft-belchior-gateway-recovery-01",
March 2021, <https://datatracker.ietf.org/doc/draft-
belchior-gateway-recovery/>.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939,
September 2010, <https://www.rfc-editor.org/info/rfc5939>. September 2010, <https://www.rfc-editor.org/info/rfc5939>.
Authors' Addresses Authors' Addresses
Martin Hargreaves Martin Hargreaves
Quant Network Quant Network
Email: martin.hargreaves@quant.network Email: martin.hargreaves@quant.network
Thomas Hardjono Thomas Hardjono
MIT MIT
Email: hardjono@mit.edu Email: hardjono@mit.edu
Rafael Belchior
Technico Lisboa
Email: rafael.belchior@tecnico.ulisboa.pt
 End of changes. 64 change blocks. 
130 lines changed or deleted 552 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/