idnits 2.17.1 draft-hargreaves-odap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2021) is 1076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'JWT' is mentioned on line 193, but not defined == Missing Reference: 'RFC 1738' is mentioned on line 488, but not defined ** Obsolete undefined reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Missing Reference: 'RFC 5939' is mentioned on line 637, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1193, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'HS19' is mentioned on line 1377, but not defined == Unused Reference: 'RFC2234' is defined on line 1403, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'HS2019' is defined on line 1419, but no explicit reference was found in the text == Unused Reference: 'NIST' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'RFC5939' is defined on line 1435, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-03) exists of draft-hardjono-blockchain-interop-arch-02 == Outdated reference: A later version (-05) exists of draft-belchior-gateway-recovery-01 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Hargreaves 3 Internet-Draft Quant Network 4 Intended status: Informational T. Hardjono 5 Expires: November 10, 2021 MIT 6 R. Belchior 7 Technico Lisboa 8 May 9, 2021 10 Open Digital Asset Protocol 11 draft-hargreaves-odap-02 13 Abstract 15 This memo describes the Open Digital Asset Protocol (ODAP). ODAP is 16 an asset transfer protocol that operates between two gateway devices. 17 The protocol includes a description of virtual or digital assets held 18 on distributed ledgers in an open and interoperable format, a session 19 negotiation part and message passing flows between gateways 20 connecting disparate distributed ledger technologies (DLTs). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 10, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. The Open Digital Asset Protocol . . . . . . . . . . . . . . . 5 60 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. ODAP Model . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Types of APIs . . . . . . . . . . . . . . . . . . . . . . 6 63 4.4. Types of Flows . . . . . . . . . . . . . . . . . . . . . 6 64 4.5. Resources and Identifiers . . . . . . . . . . . . . . . . 7 65 4.6. Access Modes . . . . . . . . . . . . . . . . . . . . . . 7 66 4.6.1. Direct Mode: Simple Client to Gateway . . . . . . . . 8 67 4.6.2. Direct Mode: Client to Multiple Gateway . . . . . . . 8 68 4.6.3. Relay Mode: Client-initiated Gateway to Gateway . . . 9 69 5. ODAP Message Format, identifiers and Descriptors . . . . . . 10 70 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2. ODAP Message Format . . . . . . . . . . . . . . . . . . . 10 72 5.3. Digital Asset Resource Descriptors . . . . . . . . . . . 11 73 5.3.1. Organisation Identifier . . . . . . . . . . . . . . . 11 74 5.3.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 12 75 5.3.3. DLT Identifier . . . . . . . . . . . . . . . . . . . 12 76 5.3.4. Resource . . . . . . . . . . . . . . . . . . . . . . 12 77 5.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12 78 5.4. Digital Asset Resource Client Descriptors . . . . . . . . 12 79 5.4.1. Organization Identifier . . . . . . . . . . . . . . . 13 80 5.4.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 13 81 5.4.3. Organizational Unit . . . . . . . . . . . . . . . . . 13 82 5.4.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . 13 84 5.5. Gateway Level Access Control . . . . . . . . . . . . . . 14 85 5.6. Negotiation of Security Protocols and Parameters . . . . 14 86 5.6.1. TLS Established . . . . . . . . . . . . . . . . . . . 14 87 5.6.2. Client offers supported credential schemes . . . . . 14 88 5.6.3. Server selects supported credential scheme . . . . . 15 89 5.6.4. Client asserts of proves identity . . . . . . . . . . 15 90 5.6.5. Sequence numbers initialized . . . . . . . . . . . . 15 91 5.6.6. Messages can now be exchanged . . . . . . . . . . . . 15 92 5.7. Asset Profile Negotiation . . . . . . . . . . . . . . . . 15 93 5.8. Application Profile Negotiation . . . . . . . . . . . . . 15 94 5.9. Digital Asset Resource Discovery . . . . . . . . . . . . 16 95 5.10. Accessing Resources via a DLT Gateway . . . . . . . . . . 16 96 5.10.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.10.2. WRITE . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.10.3. INVOKE . . . . . . . . . . . . . . . . . . . . . . . 17 99 5.10.4. LOCK . . . . . . . . . . . . . . . . . . . . . . . . 17 100 5.10.5. UNLOCK . . . . . . . . . . . . . . . . . . . . . . . 17 101 5.10.6. TRANSFER . . . . . . . . . . . . . . . . . . . . . . 17 102 5.10.7. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 17 103 5.10.8. DESTROY . . . . . . . . . . . . . . . . . . . . . . 17 104 5.10.9. READ . . . . . . . . . . . . . . . . . . . . . . . . 17 105 5.10.10. NATIVE_TXN . . . . . . . . . . . . . . . . . . . . . 17 106 5.11. Response Codes . . . . . . . . . . . . . . . . . . . . . 17 107 5.12. Backward Compatibility . . . . . . . . . . . . . . . . . 18 108 6. Transfer Initiation Flow (Phase 1) . . . . . . . . . . . . . 18 109 6.1. Initialization Request Message . . . . . . . . . . . . . 19 110 6.2. Initialization Request Message Response (ACK) . . . . . . 20 111 7. Lock-Evidence Verification Flow (Phase 2) . . . . . . . . . . 21 112 7.1. Transfer Commence Message . . . . . . . . . . . . . . . . 22 113 7.2. Transfer Commence Response Message (Ack) . . . . . . . . 23 114 7.3. Lock Evidence Message . . . . . . . . . . . . . . . . . . 24 115 7.4. Lock Evidence Response Message (Ack) . . . . . . . . . . 25 116 8. Commitment Establishment Flow (Phase 3) . . . . . . . . . . . 26 117 8.1. Commit Preparation Message . . . . . . . . . . . . . . . 26 118 8.2. Commit Preparation Response . . . . . . . . . . . . . . . 27 119 8.3. Commit Final Message . . . . . . . . . . . . . . . . . . 28 120 8.4. Commit Final Response Message . . . . . . . . . . . . . . 28 121 8.5. Transfer Complete Message . . . . . . . . . . . . . . . . 29 122 9. Security Consideration . . . . . . . . . . . . . . . . . . . 30 123 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 30 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 125 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 126 11.2. Informative References . . . . . . . . . . . . . . . . . 31 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 129 1. Introduction 131 There is a lack of interoperability between individual blockchains, 132 but also a general difficulty building open DLT networks. Extant 133 networks are custom built and relatively closed, usually limited to 134 networks of a single DLT type. 136 This memo proposes at DLT-agnostic protocol in order to allow the 137 creation of business applications that use and modify multiple DLTs, 138 through a single programmatic interface. 140 The target DLTs can be of any type, operated by different owners and 141 managed using different DLT interoperability / management platforms 142 that implement ODAP interfaces. 144 These platforms may act as gateways or relays for the application to 145 interact with the hosted DLTs. They are referred to herein as DLT 146 Gateways. 148 When correctly implemented and deployed, the protocol should provide 149 the basis for solutions involving asset migration between two DLT 150 systems, as well as use-cases when one side is non-DLT system (e.g. 151 legacy system). 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 In this document, these words will appear with that interpretation 160 only when in ALL CAPS. Lower case uses of these words are not to be 161 interpreted as carrying significance described in RFC 2119. 163 3. Terminology 165 The following are some terminology used in the current document. 166 Further terminology can be found in [Arch]. 168 Client application: This is the application employed by a user to 169 interact with a gateway node. 171 Gateway: The node of the DLT system functionally capable of acting as 172 a gateway in an asset transfer. 174 Sender gateway: The gateway that initiates a unidirectional asset 175 transfer. 177 Recipient gateway: The gateway that is the recipient side of a 178 unidirectional asset transfer. 180 DLT resources: The various interior protocols, data structures and 181 cryptographic constructs that are a core part of a DLT system. 183 Off-DLT resources: The various resources that are outside a DLT 184 system, and are not part of the operations of the DLT system. 186 Role: As in the classic client-server roles. In the gateway-to- 187 gateway interaction, one gateway will take the role of the client 188 while the other takes the role of the server, depending on the type 189 of interaction flow. 191 Claim: An assertion made by an Entity [JWT]. 193 Claim Type: Syntax used for representing a Claim Value [JWT]. 195 DLT Claim: An assertion made by a Gateway regarding the status or 196 condition of resources (e.g. asset, public keys, etc.) accessible to 197 that gateway within its DLT system. 199 4. The Open Digital Asset Protocol 201 4.1. Overview 203 The Open Digital Asset Protocol (ODAP) is a gateway-to-gateway 204 protocol used by a sender gateway with a recipient gateway to perform 205 a unidirectional transfer of a virtual asset [Arch]. 207 The protocol defines a number of API endpoints, resources and 208 identifier definitions, and message flows corresponding to the asset 209 transfer between the two gateways. 211 +----------+ +----------+ 212 | Client | | Off-DLT | 213 | (Applic) | | Resource | 214 +----------+ +----------+ 215 | |API Type-3| 216 | +----------+ 217 | ^ 218 V | 219 +----------+ | 220 |API Type-1| | 221 +------+ +----------+----+ +----+----------+ +------+ 222 | | | | | | | | | | 223 | DLT | | Gateway |API | |API | Gateway | | DLT | 224 | L1 |---| G1 |Type|<------>|Type| G2 |---| L2 | 225 | | | | 2 | | 2 | | | | 226 +------+ +----------+----+ +----+----------+ +------+ 228 Figure 1 230 4.2. ODAP Model 232 Following the gateway interoperability architecture [Arch], the model 233 for ODAP is shown in Figure 1. 235 The Client (application) interacts with its local gateway (G1) over 236 an interface (API Type-1) in order to provide instructions to the 237 gateway with regards to actions related resources located in the 238 local DLT system (L1) and resources located in remote DLT system 239 (L2). 241 Gateways interact with each other over a gateway interface (API Type- 242 2). A given gateway may be required to access resources that are not 243 located in DLT system L1 or DLT system L2. Access to these types of 244 resources are performed over an Off-DLT interface (API Type-3). 246 4.3. Types of APIs 248 The following are the types of APIs in ODAP: 250 o Gateway APIs for client (API Type-1): This the REST APIs that 251 permit a Client (application) to interact with a local gateway, 252 and issue instructions for actions pertaining to resources 253 accessible to the gateway in the local DLT system. 255 o Gateway APIs for peer gateways (API Type-2): This is the REST APIs 256 employed by two (2) peer gateways in performing unidirectional 257 asset transfers. 259 o APIs for validation of off-DLT resources (API Type-3): This is the 260 REST APIs made available by a resource server (resource owner) at 261 which a gateway can access Off-DLT resources. 263 The use of these APIs is dependent on the mode of access and the type 264 of flow in question. 266 4.4. Types of Flows 268 The ODAP protocol defines the following three (3) flows: 270 o Transfer Initiation flow: This flow deals with the asset profile 271 verification, asset ownership evidence verification and identities 272 verification. 274 o Lock-Evidence flow: This flow deals with the conveyance of 275 evidence regarding the lock (escrow) status of an asset by one 276 gateway, and the verification of the evidence by the other 277 gateway. 279 o Commitment Establishment flow: This flow deals with the asset 280 transfer and commitment establishment between two gateways on 281 behalf of their DLT systems. 283 These flow will be discussed below. 285 4.5. Resources and Identifiers 287 o (a) Resource addressing for DLTs, using the URL syntax. 289 o (b) Client identification based on the URN format. These are for 290 identifying clients (developers and applications) who access these 291 resources, and which in some use-cases require access 292 authorization. 294 o (c) Protocol message family for negotiating authentication, 295 authorisation, and parameters for confidential channel 296 establishment. 298 o (d) Resource discovery mechanism for developers and applications 299 to discover DLT-based resources hosted at a DLT gateway. The 300 gateway response is subject to the level of access granted to that 301 developer or application. 303 4.6. Access Modes 305 This draft proposes three (3) distinct mode of operation for Clients 306 when accessing resources recorded a DLT. These modes make use of a 307 gateway, with the assumption that a gateway has full access to the 308 DLT behind the gateway. 310 +----------+ 311 | Client | 312 | (Applic) | 313 +----------+ 314 | 315 | 316 (1) 317 | 318 V 319 +----------+ 320 |API Type-1| 321 +------+ +----------+----+ 322 | | | | | 323 | DLT | | Gateway |API | 324 | L1 |<--(2)---| G1 |Type| 325 | | | | 2 | 326 +------+ +----------+----+ 328 Figure 2 330 4.6.1. Direct Mode: Simple Client to Gateway 332 In this mode, the client uses its local gateway known to the client 333 in order to access (e.g. local transactions to) the local DLT. This 334 is shown in Figure 2. 336 In the direct mode, the simplest case, a client application interacts 337 with a single DLT gateway in order to interact with the DLTs hosted 338 behind the gateway. 340 The application must be recognized and authorized by the gateway. 341 Asset transfers between the DLTs behind the gateway are possible, and 342 the set of operations specified in section 5.10 MUST be supported by 343 the DLT Gateway. 345 Additional operations specific to DLT or Gateway implementations MAY 346 also be available. 348 +----------+ 349 | Client | 350 | (Applic) |------(1)--------- 351 +----------+ | 352 | | 353 (1) | 354 | | 355 V V 356 +----------+ +----------+ 357 |API Type-1| |API Type-1| 358 +------+ +----------+ +----------+ +------+ 359 | | | | | | | | 360 | DLT | | Gateway | | Gateway | | DLT | 361 | L1 |<-(2)-| G1 | | G2 |-(2)->| L2 | 362 | | | | | | | | 363 +------+ +----------+ +----------+ +------+ 365 Figure 3 367 4.6.2. Direct Mode: Client to Multiple Gateway 369 In this mode, the client is interacting with multiple gateways 370 simultaneously in order to access the DLTs behind each of those 371 gateways. The client is assumed to be performing the synchronization 372 of actions while interacting these gateways. This is illustrated in 373 Figure 3. 375 Direct mode can support connections from a single application to 376 multiple DLT gateways. The applications may assert different 377 identities with each gateway, provided it has the relevant 378 credentials. 380 The applications can interact with the DLTs behind each gateway 381 according to the authorizations granted by the gateways. 383 Asset transfers between/across DLTs hosted behind different gateways 384 are not supported in this mode. 386 4.6.3. Relay Mode: Client-initiated Gateway to Gateway 388 In this mode, the application interacts with a single Gateway, and 389 that Gateway acts as an intermediary to other Gateways. 391 Connection types and security methods used in the application to 392 gateway connection can differ from those used in the gateway to 393 gateway connection(s). The authorization method and credentials 394 presented on behalf of the application must be acceptable to the 395 final target gateway(s). 397 In Relay Mode, additional functionality is available. Asset 398 transfers, based on a two/three phase commit are available. These 399 rely on evidence of locks on source DLTs, which can be passed from 400 Gateway to Gateway, insulating the application from the additional 401 complexity and keeping the lock data private from the application. 403 Compliant Gateways MUST implement these operations, in order to 404 support Relay Mode. 406 Multi-hop connections between gateways are out of scope of this 407 document. 409 +----------+ 410 | Client | 411 | (Applic) | 412 +----------+ 413 | 414 (1) 415 | 416 V 417 +----------+ 418 |API Type-1| 419 +------+ +----------+----+ +----+-------+ +------+ 420 | | | | | | | | | | 421 | DLT | | Gateway |API |--(2)--->|API |Gateway| | DLT | 422 | L1 |<-(4)-| G1 |Type| |Type| G2 |-(4)->| L2 | 423 | | | | 2 |<---(3)--| 2 | | | | 424 | | | | | | | | | | 425 +------+ +----------+----+ +----+-------+ +------+ 427 Figure 4 429 5. ODAP Message Format, identifiers and Descriptors 431 5.1. Overview 433 This section describes (i) the phases of the ODAP protocol; (ii) the 434 format of ODAP messages; (iii) the format for resource descriptors; 435 (iv) a method for gateways to implement access controls; (iv) 436 protocol for negotiating security capabilities; (v) discovery and 437 accessing resources and provisions for backward compatibility with 438 existing systems. 440 5.2. ODAP Message Format 442 ODAP messages are exchanged between applications (clients) and DLT 443 gateways (servers). They consist of protocol negotiation and 444 functional messages. 446 Messages are JSON format, with protocol specific mandatory fields, 447 support for arbitrary authentication and authorization schemes and 448 support for a free format field for plaintext or encrypted payloads 449 directed at the DLT gateway or an underlying DLT. 451 JSON format message, mandatory fields are shown below: 453 o Version: ODAP protocol Version (major, minor). 455 o Session ID: unique identifier (UUIDv2) representing a session 456 o Sequence Number: monotonically increasing counter that uniquely 457 represents a message from a session. 459 o ODAP Phase: The current ODAP phase. 461 o Resource URL: Location of Resource to be accessed. 463 o Developer URN: Assertion of developer / application identity. 465 o Action/Response: GET/POST and arguments (or Response Code) 467 o Credential Profile: Specify type of auth (e.g. SAML, OAuth, 468 X.509) 470 o Credential Block: Credential token, certificate, string 472 o Payload Profile: Asset Profile provenance and capabilities 474 o Application Profile: Vendor or Application specific profile 476 o Payload: Payload for POST, responses, and native DLT txns. The 477 payload is specific to the current ODAP phase. 479 o Payload Hash: hash of the current message payload. 481 o Message signature: Gateway EDCSA signature over the message 483 Other relevant attributes may exists that need to be captured for 484 logging purposes. See [ODAP-2PC]. 486 5.3. Digital Asset Resource Descriptors 488 Resources are identified by URL [RFC 1738] as described below: 490 o The type is new: application/odapres 492 o The access protocol is ODAP. 494 Data included in the URL includes the folowing: 496 5.3.1. Organisation Identifier 498 This Legal Entity Identifier (LEI) or other identifier linking 499 resource ownership to real world entity. Any scheme for identifying 500 DLT Gateway owners may be implemented (e.g. LEI directory, closed 501 user group membership, SWIFT BIC, etc.). 503 The developer or application MAY validate the identity with the 504 issuing authority. The identifier is not a trusted identity, but MAY 505 be relied on where trust has been established between the two parties 506 (e.g. in a closed user group). 508 The mechanisms to determine organizations identifiers is out of scope 509 for the current specification. 511 5.3.2. DLT Gateway / Endpoint ID 513 FQDN of the ODAP compliant DLT gateway. Required to establish IP 514 connectivity. This MUST resolve to a valid IP address. 516 5.3.3. DLT Identifier 518 Specify to gateway behind which the target DLTs operates. This field 519 is local to the DLT gateway and is used to direct ODAP interactions 520 to the correct underlying DLT. 522 For example: "Hyperledger1", "Bitcoin, "EU-supply-chain". 524 5.3.4. Resource 526 Specifies a resource held on the underlying DLT. This field must be 527 meaningful to the DLT in question but is otherwise an arbitrary 528 string. The underlying object it points to may be a DLT address, 529 block, transaction ID, alias, etc. or a future object type not yet 530 defined. 532 5.3.5. Examples 534 odapres://quant/api.gateway1.com/ripple 536 odapres://quant/api.gateway1.com/bitcoin/xxxxxADDRESSxxxxx 538 5.4. Digital Asset Resource Client Descriptors 540 Resources are identified by URN as described below: 542 o The type is new: application/odapclient 544 The URN format does not imply availability or access protocol. 546 Data included in the URN includes the folowing: 548 5.4.1. Organization Identifier 550 Legal Entity Identifier (LEI) or other identifier linking resource 551 ownership to real world entity. Any scheme for identifying DLT 552 Gateway owners may be implemented (e.g. LEI directory, closed user 553 group membership, BIC, etc.). 555 The DLT Gateway MAY validate the identity with the issuing authority. 556 The identifier is not a trusted identity, but MAY be relied on where 557 trust has been established between the two parties (e.g. in a closed 558 user group). 560 5.4.2. DLT Gateway / Endpoint ID 562 Multi-DLT applications can operate in a mode whereby the application 563 connects to its local DLT gateway, which then forwards application 564 traffic to local DLTs and to remote DLTs via other ODAP gateways. 566 Where this is the case, this field identifies the "home" gateway for 567 this application. This may be required to carry out Gateway to 568 Gateway handshaking and protocol negotiation, or for the server to 569 look up use case specific data relating to the client. 571 5.4.3. Organizational Unit 573 The organization unit within the organization that the client 574 (application or developer) belongs to. This assertion should be 575 backed up with authentication via the negotiated protocol. 577 The purpose of this field is to allow DLT gateways to maintain access 578 control mapping between applications and resources that are 579 independent of the authentication and authorization schemes used, 580 supporting future changes and supporting counterparties that operate 581 different schemes. 583 5.4.4. Name 585 A locally unique (within the OU) identifier, which can identify the 586 application, project or individual developer responsible for this 587 client connection. This is the most granular unit of access control, 588 and DLT Gateways should ensure appropriate identifiers are used for 589 the needs of the application or use case. 591 5.4.5. Examples 593 odapclient:quant/api.overledger.quant.com/research/luke.riley 595 5.5. Gateway Level Access Control 597 Gateways can enforce access rules based on standard naming 598 conventions using novel or existing mechanisms such as AuthZ 599 protocols using the resource identifiers above, for example: 601 odapclient://hsbc/api.overledger.hsbc.com/lending/eric.devloper 603 can READ/WRITE 605 odapres://quant/api.gateway1.com/bitcoin 607 AND 609 odapres://quant/api.gateway1.com/ripple 611 These rules would allow a client so identified to access resources 612 directly, for example: 614 odapres://quant/api.gateway1.com/bitcoin/xxxxxADDRESSxxxxx 616 This example could be an client subscribing to or writing to an 617 address associated with a smart contract as part of its 618 functionality. 620 This method allows resource owners to easily grant access to 621 individuals, groups and organizations. Individual gateway 622 implementations may implement access controls, including subsetting 623 and supersetting or applications or resources according to their own 624 requirements. 626 5.6. Negotiation of Security Protocols and Parameters 628 5.6.1. TLS Established 630 TLS 1.2 or higher MUST be implemented to protect gateway 631 communications. TLS 1.3 or higher SHOULD be implemented where both 632 gateways support TLS 1.3 or higher. 634 5.6.2. Client offers supported credential schemes 636 Capability negotiation prior to data exchange, follows a scheme 637 similar to the Session Description Protocol [RFC 5939]. Initially 638 the client (application) sends a JSON block containing acceptable 639 credential schemes, e.g. OAuth2.0, SAML in the "Credential Scheme" 640 field of the ODAP message. 642 5.6.3. Server selects supported credential scheme 644 The server (DLT Gateway) selects one acceptable credential scheme 645 from the offered schemes, returning the selection in the "Credential 646 Scheme" field of the ODAP message. 648 If no acceptable credential scheme was offered, an HTPP 511 "Network 649 Authentication Required" error is returned in the Action/Response 650 field of the ODAP message. 652 5.6.4. Client asserts of proves identity 654 The details of the assertion / verification step are specific to the 655 chosen credential scheme and are out of scope of this document. 657 5.6.5. Sequence numbers initialized 659 Sequence numbers are used to allow the server to correctly order 660 operations from the client, some of which may be asynchronous, 661 synchronous, idempotent with duplicate requests handled in different 662 ways according to the use case. 664 The initial sequence number is proposed by the client (Application) 665 after the finalization of credential verification. The server (DLT 666 gateway) MUST respond with the same sequence number to indicate 667 acceptance. 669 The client (application) increments the sequence number with each new 670 request. Sequence numbers can be reused for retries in the event of 671 a gateway timeout. 673 5.6.6. Messages can now be exchanged 675 Handshaking is complete at this point, and the client (application) 676 can send ODAP messages to perform actions of DLT resources, which MAY 677 reference the ODAP Payload field. 679 5.7. Asset Profile Negotiation 681 TBD 683 5.8. Application Profile Negotiation 685 Where an application relies on specific extensions for operation, 686 these can be represented in an Application Profile. 688 For example, a payments application tracks payments through the use 689 of a cloud based API and will only interact with Gateways that log 690 messages to that API, a resource profile can be established: 692 Application Name: TRACKER 694 X-Tracker_URL: https://api.tracker.com/updates 696 X-Tracking-Policy: Always 698 As Gateways implement this functionality, they support the TRACKER 699 application profile, and the application is able to expand its reach 700 by periodically polling for the availability of the profile. 702 This is an intentionally generalized extension mechanism for 703 application or vendor specific functionality. 705 5.9. Digital Asset Resource Discovery 707 Applications MUST be able to discover which resources they are 708 authorized to access to the level of individual DLTs. They MAY be 709 able to discover lower level resources. 711 Resource discovery is handled by the DLT gateway, for instance a GET 712 request against the gateway URL with no DLT or resource could return 713 a list of URLs available to the requester to DLT level. This list is 714 subject to the access controls above. 716 DLT Gateways MAY allow applications to discover resources they do not 717 have access to, this should be indicated the free text field, and 718 they should implement a process for applications to request access. 720 Formal specification of supported resource discovery methods is out 721 of scope of this document. 723 5.10. Accessing Resources via a DLT Gateway 725 The Action field is used to access resources via the gateway. We 726 suggest these interactions use REST semantics however a detailed API 727 specification is out of scope of this memo. 729 In general, we suggest exposing a common subset of functionality via 730 API using the Action field, augmented with DLT specific or smart 731 contract specific functionality as needed. 733 5.10.1. CREATE 735 Create an object on the target DLT. 737 5.10.2. WRITE 739 Write to a location on the target DLT. 741 5.10.3. INVOKE 743 Invoke code on the target DLT (typically a smart contract). 745 5.10.4. LOCK 747 Lock an object on the target DLT. 749 5.10.5. UNLOCK 751 Unlock an object on the target DLT. 753 5.10.6. TRANSFER 755 Transfer an object from one DLT to another. 757 5.10.7. SUBSCRIBE 759 Subscribe to be notified of transaction affecting an object on the 760 target DLT. 762 5.10.8. DESTROY 764 Destroy an object on the target DLT. 766 5.10.9. READ 768 Read an object from the target DLT. 770 5.10.10. NATIVE_TXN 772 Send a signed native transaction of any kind to the target DLT. 773 Payload consists of the native transaction. 775 5.11. Response Codes 777 The DLT Gateway MUST respond with return codes indicating the failure 778 or success of the operation. For DLTs with slow consensus mechanism, 779 the Gateway may return codes indicating the operation has been 780 submitted. The application may carry out further operation in future 781 to determine the ultimate status of the operation. 783 For Non-native transactions, the Gateway is responsible for 784 translating the request into the appropriate native format and 785 ensuring correct signing takes place. 787 5.12. Backward Compatibility 789 It is also possible to send a fully formatted native message to the 790 underlying DLT in the Payload field using the NATIVE_TXN operation, 791 directed to a resource URL. This allows existing DLT native code to 792 be ported to ODAP infrastructures with minimal change. 794 6. Transfer Initiation Flow (Phase 1) 796 This section describes ODAP initialization phase, where a sender 797 gateway interacts with a target gateway, proposing a session. 799 For this, several artifacts need to be validated: asset profile, 800 asset ownership evidence, identities, and logging-related operations 801 (log profile, access control profile [ODAP-2PC]). 803 In this phase, gateways implement the Transfer Initiation Flows 804 endpoint. 806 In the following, the sender gateway takes instructions from a client 807 application, while the recipient gateway may act on behalf of 808 clients. 810 The flow follows a request-response model. The sender gateway makes 811 a request (POST) to the Transfer Initiation endpoint at the recipient 812 gateway. 814 Gateways MUST support the use of the HTTP GET and POST methods 815 defined in RFC 2616 [RFC2616] for the endpoint. 817 Clients MAY use the HTTP GET or POST methods to send messages in this 818 phase to the server. If using the HTTP GET method, the request 819 parameters maybe serialized using URI Query String Serialization. 821 The client and server may be required to sign certain messages in 822 order to provide standalone proof (for non-repudiation) independent 823 of the secure channel between the client and server. This proof 824 maybe required for audit verifications post-event. 826 (NOTE: Flows occur over TLS. Nonces are not shown). 828 6.1. Initialization Request Message 830 This message is sent from the sender gateway to the recipient 831 gateway. Note that a client (application) can issue an asset 832 transfer, that is sent to the gateway and converted into an 833 Initialization Request Message. 835 The purpose of this message is for the client to initiate an asset 836 transfer via its gateway. Depending on the proposal, multiple rounds 837 of communication between clients and gateways, and between gateways 838 may happen. 840 The parameters of this message consists of the following: 842 o Version: ODAP protocol Version (major, minor). 844 o Developer URN: Assertion of developer / application identity. 846 o Credential Profile: Specify type of auth (e.g. SAML, OAuth, 847 X.509) 849 o Payload Profile: Asset Profile provenance and capabilities 851 o Application Profile: Vendor or Application specific profile 853 o logging_profile REQUIRED: contains the profile regarding the 854 logging procedure. Default is local store. 856 o Access_control_profile REQUIRED: the profile regarding the 857 confidentiality of the log entries being stored. Default is only 858 the gateway that created the logs can access them. 860 o Initialization Request Message signature REQUIRED: Gateway EDCSA 861 signature over the message 863 o Source_gateway_pubkey REQUIRED: the public key of the gateway 864 initiating a transfer 866 o Source_gateway_dlt_system REQUIRED: the ID of the source DLT 868 o Recipient_gateway_pubkey REQUIRED: the public key of the gateway 869 involved in a transfer 871 o Recipient_gateway_dlt_system REQUIRED: the ID of the recipient 872 gatewayinvolved in a transfer 874 o Escrow type: faucet, timelock, hashlock, hashtimelock, multi-claim 875 PC, destroy/burn (escrowed cross-claim). 877 o Expiry time: when will the escrow expire 879 o Multiple claims allowed: true/false 881 o Multiple cancels allowed: true/false 883 o Permissions: list of identities (addresses/X.509 certificates) 884 that can perform operations on the escrow 886 o Origin: along with the source gateway DLT, allows identifying from 887 where are the funds escrowed/provided 889 o Destination: along with the recipient gateway DLT, allows 890 identifying to where are the escrowed funds going 892 o Subsequent calls: details possible escrow actions 894 o History: provides an history of the escrow, in case it has 895 previously been initialized. This includes a list of the 896 transactions on that escrow (transaction ID) and which action it 897 performed (ActionCategory), the origin and destination, balance, 898 current status, and ActionLockSpecificParameters. 900 The sender gateway makes the following HTTP request using TLS (with 901 extra line breaks for display purposes only). 903 Example: TBD. 905 6.2. Initialization Request Message Response (ACK) 907 After receiving an Initialization Request Message, the recipient 908 gateway needs to validate the profiles. 910 This validation could be performed automatically (using a defined set 911 of rules), or by requiring approval by a client application. 913 If one of the profiles is rejected, the recipient gateway constructs 914 a Initialization Denied Message, stating what was rejected, and 915 proposing an alternative (if applicable). 917 Otherwise, if approved, the recipient gateway constructs a 918 Initialization Request Message Response. 920 The purpose of this message is for the server to indicate agreement 921 to proceed with the proposed operations, under the proposed profiles. 923 This message is sent from the recipient gateway to the sender gateway 924 in response to a Initialization Request from the sender gateway. 926 The message must be signed by the server. 928 The parameters of this message consists of the following: 930 o Session ID: unique identifier (UUIDv2) representing a session. 932 o Sequence Number: monotonically increasing counter that uniquely 933 represents a message from a session. 935 o ODAP Phase: The current ODAP phase. 937 o Hash of the Initialization Request Message REQUIRED: the hash of 938 the proposal. 940 o Destination: if the recipient gateway calculates the destination 941 address dynamically. 943 o Timestamp REQUIRED: timestamp referring to when the Initialization 944 Request Message was received. 946 o Processed Timestamp REQUIRED: timestamp referring to when the 947 Initialization Response Message was constructed. 949 Example: TBD. 951 7. Lock-Evidence Verification Flow (Phase 2) 953 This section describes the conveyance of claims regarding to the 954 status of assets or resources from a sender gateway to a recipient 955 gateway. 957 In this phase, gateways implement the Lock-Evidence Agreement 958 endpoint. 960 In the following, the sender gateway takes the role of the client 961 while the recipient gateway takes the role of the server. 963 The flow follows a request-response model. The client makes a 964 request (POST) to the Lock-Evidence Agreement endpoint at the server. 966 Gateways MUST support the use of the HTTP GET and POST methods 967 defined in RFC 2616 [RFC2616] for the endpoint. 969 Clients MAY use the HTTP GET or POST methods to send messages in this 970 phase to the server. If using the HTTP GET method, the request 971 parameters maybe serialized using URI Query String Serialization. 973 The client and server may be required to sign certain messages in 974 order to provide standalone proof (for non-repudiation) independent 975 of the secure channel between the client and server. This proof 976 maybe required for audit verifications post-event. 978 (NOTE: Flows occur over TLS. Nonces are not shown). 980 7.1. Transfer Commence Message 982 This message is sent from the client (sender gateway) to the Transfer 983 Request Endpoint at the server. It signals to the server that the 984 client is ready to start the transfer of the digital asset. 986 The message must contain claims related to the information from the 987 previous flow (Phase 1). It must be signed by the client (sender 988 gateway). 990 The parameters of this message consists of the following: 992 o message_type REQUIRED. MUST be the value 993 urn:ietf:odap:msgtype:transfer-commence-msg 995 o originator_pubkey REQUIRED. This is the public key of the asset 996 owner (originator) in the origin DLT system. 998 o beneficiary_pubkey REQUIRED. This is the public key of the 999 beneficiary in the destination DLT system. 1001 o sender_dlt_system REQUIRED. This is the identifier of the origin 1002 DLT system behind the client. 1004 o recipient_dlt_system REQUIRED. This is the identifier of the 1005 destination DLT system behind the server. 1007 o client_identity_pubkey REQUIRED. The client who sent this 1008 message. 1010 o server_identity_pubkey REQUIRED. The server for whom this message 1011 is intended. 1013 o hash_asset_profile REQUIRED. This is the hash of the asset 1014 profile previously agreed upon in Phase 1. 1016 o asset_unit OPTIONAL. If applicable this is the unit amount of the 1017 asset being transferred, previously agreed upon. 1019 o hash_prev_message REQUIRED. The hash of the last message in Phase 1020 1. 1022 o client_transfer_number OPTIONAL. This is the transfer 1023 identification number chosen by the client. This number is 1024 meaningful only the client. 1026 o client_signature REQUIRED. The digital signature of the client. 1028 For example, the client makes the following HTTP request using TLS 1029 (with extra line breaks for display purposes only): 1031 POST /token HTTP/1.1 1032 Host: server.example.com 1033 Authorization: Basic awHCaGRSa3F0MzpnWDFmQmF0M2ZG 1034 Content-Type: application/x-www-form-urlencoded 1036 { 1037 "message_type": "urn:ietf:odap:msgtype:transfer-commence-msg", 1038 "originator_pubkey":"zGy89097hkbfgkjvVbNH", 1039 "beneficiary_pubkey": "mBGHJjjuijh67yghb", 1040 "sender_dlt_system": "originDLTsystem", 1041 "recipient_dlt_system":"recipientDLTsystem", 1042 "client_identity_pubkey":"fgH654tgeryuryuy", 1043 "server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334", 1044 "hash_asset_profile":"nbvcwertyhgfdsertyhgf2h3v4bd3v21", 1045 "asset_unit": "ghytredcfvbhfr", 1046 "hash_prev_message":"DRvfrb654vgreDerverv654nhRbvder4", 1047 "client_transfer_number":"ji9876543ewdfgh", 1048 "client_signature":"fdw34567uyhgfer45" 1049 } 1051 Figure 5 1053 7.2. Transfer Commence Response Message (Ack) 1055 The purpose of this message is for the server to indicate agreement 1056 to proceed with the asset transfer. 1058 This message is sent from the server (recipient gateway) to client 1059 (sender gateway) in response to a Transfer Commence Request from the 1060 client. 1062 The message must be signed by the server. 1064 The parameters of this message consists of the following: 1066 o message_type REQUIRED urn:ietf:odap:msgtype:transfer-commenceack- 1067 msg 1069 o client_identity_pubkey REQUIRED. The client for whom this message 1070 is intended. 1072 o server_identity_pubkey REQUIRED. The server who sent this 1073 message. 1075 o hash_commence_request REQUIRED. The hash of previous message. 1077 o server_transfer_number OPTIONAL. This is the transfer 1078 identification number chosen by the server. This number is 1079 meaningful only to the server. 1081 o server_signature REQUIRED. The digital signature of the server. 1083 An example of a success response could be as follows: 1085 ``` 1086 HTTP/1.1 200 OK 1087 Content-Type: application/json;charset=UTF-8 1088 Cache-Control: no-store 1089 Pragma: no-cache 1091 { 1092 "message_type":"urn:ietf:odap:msgtype:transfer-commenceack-msg", 1093 "client_identity_pubkey":"fgH654tgeryuryuy", 1094 "server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334", 1095 "hash_commence_request":"DRvfrb654vgreDerverv654nhRbvder4", 1096 "server_transfer_number":"ji9876543ewdfgh", 1097 "server_signature":"aaw34567uyhgfer66" 1098 } 1099 ``` 1101 Figure 6 1103 7.3. Lock Evidence Message 1105 The purpose of this message is for the client (sending gateway) to 1106 deliver the relevant asset-lock (or escrow) evidence to the server 1107 (recipient gateway). 1109 The format of the evidence is dependent on the DLT fronted by the 1110 client and is outside the scope of this specification. 1112 The message must be signed by the client. 1114 This message is used client (sender gateway) to convey lock/escrow 1115 evidence to the server (recipient gateway). 1117 This message is sent from the client to the Evidence Validation 1118 Endpoint at the server. The server must validate the lock evidence 1119 claims in this message. 1121 The message must be signed by the client (sender gateway). 1123 The parameters of this message consists of the following: 1125 o message_type REQUIRED urn:ietf:odap:msgtype:lock-evidence-req-msg 1127 o client_identity_pubkey REQUIRED. The client who sent this 1128 message. 1130 o server_identity_pubkey REQUIRED. The server for whom this message 1131 is intended. 1133 o lock_evidence_claim REQUIRED. The lock or escrow evidence (on the 1134 ledger L1 fronted by the client G1). 1136 o lock_claim_format OPTIONAL. The format of the evidence. 1138 o lock_evidence_expiration REQUIRED. The duration of time of lock 1139 on ledger L1 (after which the lock is released). 1141 o hash_commence_ack_request REQUIRED. The hash of previous message. 1143 o client_transfer_number OPTIONAL. This is the transfer 1144 identification number chosen by the client. This number is 1145 meaningful only to the client. 1147 o client_signature REQUIRED. The digital signature of the client. 1149 7.4. Lock Evidence Response Message (Ack) 1151 The purpose of this message is for the server (recipient gateway) to 1152 indicate accaptance of the asset-lock (or escrow) evidence delivered 1153 by the client (sending gateway) in the previous message. 1155 The message must be signed by the server. 1157 The parameters of this message consists of the following: 1159 o message_type REQUIRED urn:ietf:odap:msgtype:lock-evidence-ack-msg 1161 o client_identity_pubkey REQUIRED. The client for whom this message 1162 is intended. 1164 o server_identity_pubkey REQUIRED. The server who sent this 1165 message. 1167 o hash_lockevidence_request REQUIRED. The hash of previous message. 1169 o server_transfer_number OPTIONAL. This is the transfer 1170 identification number chosen by the server. This number is 1171 meaningful only to the server. 1173 o server_signature REQUIRED. The digital signature of the server. 1175 8. Commitment Establishment Flow (Phase 3) 1177 This section describes the transfer commitment agreement between the 1178 sender gateway to a recipient gateway. 1180 This phase must be completed within the asset-lock duration time 1181 specificied in the previous lock_evidence_expiration parameter 1182 (message 7.3). 1184 In this phase gateways implement the Transfer Commitment endpoint. 1186 In the following, the sender gateway takes the role of the client 1187 while the recipient gateway takes the role of the server. 1189 The flow follows a request-response model. The client makes a 1190 request (POST) to the Transfer Commitment endpoint at the server. 1192 Gateways MUST support the use of the HTTP GET and POST methods 1193 defined in RFC 2616 [RFC2616] for the endpoint. 1195 Clients MAY use the HTTP GET or POST methods to send messages in this 1196 phase to the server. If using the HTTP GET method, the request 1197 parameters maybe serialized using URI Query String Serialization. 1199 The client and server may be required to sign certain messages in 1200 order to provide standalone proof (for non-repudiation) independent 1201 of the secure channel between the client and server. This proof 1202 maybe required for audit verifications post-event. 1204 (NOTE: Flows occur over TLS. Nonces are not shown). 1206 8.1. Commit Preparation Message 1208 The purpose of this message is for the client to indicate its 1209 readiness to begin the commitment of the transfer. 1211 The message must be signed by the client. 1213 The parameters of this message consists of the following: 1215 o message_type REQUIRED. It MUST be the value 1216 urn:ietf:odap:msgtype:commit-prepare-msg 1218 o client_identity_pubkey REQUIRED. The client who sent this 1219 message. 1221 o server_identity_pubkey REQUIRED. The server for whom this message 1222 is intended. 1224 o hash_lockevidence_ack REQUIRED. The hash of previous message. 1226 o client_transfer_number OPTIONAL. This is the transfer 1227 identification number chosen by the client. This number is 1228 meaningful only the client. 1230 o client_signature REQUIRED. The digital signature of the client. 1232 8.2. Commit Preparation Response 1234 The purpose of this message is for the server to indicate to the 1235 client its readiness to proceed with the commitment finalization 1236 step.. 1238 The message must be signed by the server. 1240 The parameters of this message consists of the following: 1242 o message_type REQUIRED. It MUST be the value 1243 urn:ietf:odap:msgtype:commit-prepare-ack-msg 1245 o client_identity_pubkey REQUIRED. The client for whom this message 1246 is intended. 1248 o server_identity_pubkey REQUIRED. The server who sent this 1249 message. 1251 o hash_commitprep REQUIRED. The hash of previous commit preparation 1252 message. 1254 o server_transfer_number OPTIONAL. This is the transfer 1255 identification number chosen by the server. This number is 1256 meaningful only the server. 1258 o server_signature REQUIRED. The digital signature of the server. 1260 8.3. Commit Final Message 1262 The purpose of this message is for the client to indicate to the 1263 server that the client (sender gateway) has completed local 1264 extinguishment of the asset on its DLT (L1), and that now on its part 1265 the server (recipient gateway) must re-generated the asset on its DLT 1266 (L2). 1268 The message must contain claims related to the extinguishment of the 1269 asset by the client. It must be signed by the client. 1271 The parameters of this message consists of the following: 1273 o message_type REQUIRED. It MUST be the value 1274 urn:ietf:odap:msgtype:commit-final-msg 1276 o client_identity_pubkey REQUIRED. The client who sent this 1277 message. 1279 o server_identity_pubkey REQUIRED. The server for whom this message 1280 is intended. 1282 o commit_final_claim REQUIRED. This is one or more claims signed by 1283 the client that the asset in question has been extinguished by the 1284 client in its local DLT. 1286 o commit_final_claim_format OPTIONAL. This is the format of the 1287 claim provided by the client in this message. 1289 o hash_commitprepare_ack REQUIRED. The hash of previous message. 1291 o client_transfer_number OPTIONAL. This is the transfer 1292 identification number chosen by the client. This number is 1293 meaningful only the client. 1295 o client_signature REQUIRED. The digital signature of the client. 1297 8.4. Commit Final Response Message 1299 The purpose of this message is for the server to indicate to the 1300 client that it has completed the asset re-generation at its DLTS 1301 (L2). 1303 The message must contain claims related to the re-generated of the 1304 asset by the server. It must be signed by the server. 1306 The parameters of this message consists of the following: 1308 o message_type REQUIRED. It MUST be the value 1309 urn:ietf:odap:msgtype:commit-final-ack-msg 1311 o client_identity_pubkey REQUIRED. The client for whom this message 1312 is intended.. 1314 o server_identity_pubkey REQUIRED. The server who sent this 1315 message. 1317 o commit_acknowledgement_claim REQUIRED. This is one or more claims 1318 signed by the server that the asset in question has been 1319 regenerated by the server in its local DLT. 1321 o commit_acknowledgement_claim_format OPTIONAL. This is the format 1322 of the claim provided by the server in this message. 1324 o hash_commitfinal REQUIRED. The hash of previous commit final 1325 message. 1327 o server_transfer_number OPTIONAL. This is the transfer 1328 identification number chosen by the server. This number is 1329 meaningful only the server. 1331 o server_signature REQUIRED. The digital signature of the server. 1333 8.5. Transfer Complete Message 1335 The purpose of this message is for the client to indicate to the 1336 server that the asset transer has been completed and that no further 1337 messages are to be expected from the client in regards to this 1338 transfer instance. 1340 The message closes the first message of Phase 2 (Transfer Commence 1341 Message). It must be signed by the client. 1343 The parameters of this message consists of the following: 1345 o message_type REQUIRED. It MUST be the value 1346 urn:ietf:odap:msgtype:commit-transfer-complete-msg 1348 o client_identity_pubkey REQUIRED. The client who sent this 1349 message. 1351 o server_identity_pubkey REQUIRED. The server for whom this message 1352 is intended. 1354 o hash_commit_final_ack REQUIRED. The hash of previous message. 1356 o hash_transfer_commence REQUIRED. The hash of the Transfer 1357 Commence message at the start of Phase 2 (see section 7.1). 1359 o client_transfer_number OPTIONAL. This is the transfer 1360 identification number chosen by the client. This number is 1361 meaningful only the client. 1363 o client_signature REQUIRED. The digital signature of the client.. 1365 9. Security Consideration 1367 Although the current interoperability architecture for blockchain 1368 gateways assumes the externalization of the value of assets, as a 1369 blockchain system holds an increasing number of virtual assets it 1370 becomes attractive to attackers seeking to obtain cryptographic keys 1371 of its nodes and its end-users. 1373 Gateway nodes are of particular interest to attackers because they 1374 enable the transferal of virtual assets to external blockchain 1375 systems, which may or may not be regulated. As such, hardening 1376 technologies and tamper-resistant crypto-processors (e.g. TPM, SGX) 1377 should be used for implementations of gateways [HS19]. 1379 Due to the consensus-based nature of the underlying DLT technologies, 1380 gateway responses may be conditional and require verification, for 1381 instance if the DLT is undergoing a byzantine attack at the time of 1382 the request. 1384 The application must evaluate the correctness of responses from the 1385 gateway in context and may need to perform further verification steps 1386 with later ODAP calls. The application may base this evaluation on 1387 the number of DLT nodes the gateway has interacted with in order to 1388 fulfil the request. 1390 10. IANA Consideration 1392 (TBD) 1394 11. References 1396 11.1. Normative References 1398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1399 Requirement Levels", BCP 14, RFC 2119, 1400 DOI 10.17487/RFC2119, March 1997, 1401 . 1403 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1404 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 1405 November 1997, . 1407 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1408 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1409 . 1411 11.2. Informative References 1413 [Arch] Hardjono, T., Hargreaves, M., and N. Smith, "An 1414 Interoperability Architecture for Blockchain Gateways. 1415 draft-hardjono-blockchain-interop-arch-02", April 2021, 1416 . 1419 [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted 1420 Computing Base for Blockchain Infrastructure Security, 1421 Frontiers Journal, Sepcial Issue on Blockchain Technology, 1422 Vol. 2, No. 24", December 2019, 1423 . 1425 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST 1426 Blockchain Technology Overview (NISTR-8202)", October 1427 2018, . 1429 [ODAP-2PC] 1430 Belchior, R., Correia, M., and T. Hardjono, "Gateway Crash 1431 Recovery Mechanism. draft-belchior-gateway-recovery-01", 1432 March 2021, . 1435 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 1436 Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, 1437 September 2010, . 1439 Authors' Addresses 1441 Martin Hargreaves 1442 Quant Network 1444 Email: martin.hargreaves@quant.network 1446 Thomas Hardjono 1447 MIT 1449 Email: hardjono@mit.edu 1450 Rafael Belchior 1451 Technico Lisboa 1453 Email: rafael.belchior@tecnico.ulisboa.pt