idnits 2.17.1 draft-belchior-gateway-recovery-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2021) is 1199 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 338 -- Looks like a reference, but probably isn't: '2' on line 341 -- Looks like a reference, but probably isn't: '3' on line 345 -- Looks like a reference, but probably isn't: '4' on line 348 -- Looks like a reference, but probably isn't: '5' on line 352 -- Looks like a reference, but probably isn't: '6' on line 355 -- Looks like a reference, but probably isn't: '7' on line 358 -- Looks like a reference, but probably isn't: '8' on line 361 -- Looks like a reference, but probably isn't: '9' on line 364 -- Looks like a reference, but probably isn't: '10' on line 367 -- Looks like a reference, but probably isn't: '11' on line 370 -- Looks like a reference, but probably isn't: '12' on line 374 -- Looks like a reference, but probably isn't: '13' on line 377 -- Looks like a reference, but probably isn't: '14' on line 380 -- Looks like a reference, but probably isn't: '15' on line 383 -- Looks like a reference, but probably isn't: '16' on line 386 == Missing Reference: 'CD16' is mentioned on line 570, but not defined == Unused Reference: 'RFC2119' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'Clar88' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'HS2019' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'SRC84' is defined on line 620, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hargreaves-odap-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Belchior 3 Internet-Draft M. Correia 4 Intended status: Informational INESC-ID, Instituto Superior Tecnico 5 Expires: July 16, 2021 T. Hardjono 6 MIT 7 January 12, 2021 9 DLT Gateway Crash Recovery Mechanism 10 draft-belchior-gateway-recovery-00 12 Abstract 14 This memo describes crash recovery mechanisms for the Open Digital 15 Asset Protocol (ODAP). The memo presents ODAP-2PC, a protocol 16 assures that gateways running ODAP are crash fault-tolerant, meaning 17 that the atomicity of asset transfers are assured even if gateways 18 crash. This protocol includes the description of the messaging and 19 logging flows necessary for gateways to keep track of current state, 20 the crash-recovery protocol, and a rollback mechanism. 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 July 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Gateway Crash Recovery . . . . . . . . . . . . . . . . . . . 3 59 3.1. Gateway Transfer Model . . . . . . . . . . . . . . . . . 4 60 3.2. Crash Recovery Model . . . . . . . . . . . . . . . . . . 6 61 3.3. Recovery Procedure . . . . . . . . . . . . . . . . . . . 6 62 3.4. Log Storage . . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Format of log entries . . . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 67 6.2. Informative References . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 70 1. Introduction 72 Gateway systems that perform virtual asset transfers among DLTs must 73 possess a degree of resiliency and fault tolerance in the face of 74 possible crashes. A key component of crash recovery is maintaining 75 logs that enable either the same or other backup gateways to resume 76 partially completed transfers. Another key component is an atomic 77 commit protocol (ACP) that guarantees that the source and target DLTs 78 are modified consistently (atomicity) and permanently (durability), 79 e.g., that assets that are taken from the source DLT are persisted 80 into the recipient DLT. 82 This document proposes: (i) the parameters that a gateway must retain 83 in the form of logs concerning message flows within asset transfers; 84 (ii) a JSON-based format for logs related to asset transfers. 86 2. Terminology 88 There following are some terminology used in the current document: 90 o Gateway: The nodes of a DLT system that are functionally capable 91 of handling an asset transfer with another DLT. Gateway nodes 92 implement the gateway-to-gateway asset transfer protocol. 94 o Primary Gateway: The node of a DLT system that has been selected 95 or elected to act as a gateway in an asset transfer. 97 o Backup Gateway: The node of a DLT system that has been selected or 98 elected to act as a backup gateway to a primary gateway. 100 o Message Flow Parameters: The parameters and payload employed in a 101 message flow between a sending gateway and receiving gateway. 103 o Source Gateway (or G1): The gateway that initiates the transfer 104 protocol. Acts as a coordinator of the ACP and mediates the 105 message flow. 107 o Recipient Gateway (or G2): The gateway that is the target of an 108 asset transfer. It follows instructions from the source gateway. 110 o Source DLT: The DLT of the source gateway. 112 o Target DLT: The DLT of the recipient gateway. 114 o Log data: The log information is retained by a gateway connected 115 to an exchanged message within an asset transfer protocol. 117 o Log entry: The log information generated and persisted by a 118 gateway regarding one specific message flow step. 120 o Log format: The format of log-data generated by a gateway. 122 o Atomic commit protocol (ACP): A protocol that guarantees that 123 assets that are taken from a DLT are persisted into the other DLT. 124 Examples are two and three-phase commit protocols (2PC, 3PC, 125 respectively) and non-blocking atomic commit protocols. 127 3. Gateway Crash Recovery 129 The gateway architecture [ODAP] defines two gateway nodes belonging 130 to distinct DLT systems as a means to conduct a virtual asset 131 transfer in a secure and non-repudiable manner while ensuring the 132 asset does not exist simultaneously on both blockchains. 134 One of the key deployment requirements of gateways for asset 135 transfers is a high degree of gateways availability. In this 136 document, we consider two common strategies to increase availability: 137 (1) to support the recovery of the gateways and (2) to employ backup 138 gateways with the ability to resume a stalled transfer. 140 To this end, gateways must retain relevant log information regarding 141 incoming protocol messages (parameters, payloads, etc.) and 142 transmitted messages. In particular, logs are written before 143 operations (write-ahead) to provide atomicity and durability to the 144 asset exchange protocol. The log-data is considered as internal 145 resources to the DLT system, accessible to the backup gateway and 146 possible other gateway nodes. 148 3.1. Gateway Transfer Model 150 The Open Digital Asset Protocol (ODAP) is a gateway-to-gateway 151 protocol used by a sender gateway and a target gateway to perform a 152 virtual asset's unidirectional transfer [ODAP]. The protocol is DLT- 153 agnostic. The transfer process is started by a Client (application) 154 that interacts with the source gateway or both (source and recipient) 155 gateways to provide instructions regarding actions, related resources 156 located in the source DLT system, and resources located in the remote 157 DLT system. The protocol has two modes, but here we consider only 158 the Relay Mode: Client-initiated Gateway to Gateway asset transfer. 159 When we refer to the ODAP protocol in this document, we refer to the 160 ODAP protocol in Relay Mode. 162 ODAP has to be instanced with an ACP protocol to guarantee that the 163 source and target DLTs are modified consistently, a property 164 designated Atomicity [BHG87]. ACPs consider two roles: a Coordinator 165 that manages the execution of the protocol and Participants that 166 manage the resources that must be kept consistent. The source 167 gateway plays the ACP role of Coordinator, and the recipient gateway 168 plays the Participant role in relay mode. The message exchange is 169 represented below: 171 ,--. ,--. ,-------. 172 |G1| |G2| |Log API| 173 `--' `--' `-------' 174 | [1]: writeLogEntry init-validate | 175 | --------------------------------------------------------------> 176 | | | 177 | [2]: initiate ODAP's phase 1| | 178 | ----------------------------> | 179 | | | 180 | | [3]: writeLogEntry exec-validate| 181 | | --------------------------------> 182 | | | 183 | |----. | 184 | | | [4]: execute init from p1 | 185 | |<---' | 186 | | | 187 | | [5]: writeLogEntry done-validate| 188 | | --------------------------------> 189 | | | 190 | | [6]: writeLogEntry ack-validate | 191 | | --------------------------------> 192 | | | 193 | [7]: validation complete | | 194 | <---------------------------- | 195 ,--. ,--. ,-------. 196 |G1| |G2| |Log API| 197 `--' `--' `-------' 199 Figure 1 201 The simplified message flow format is in the form < ODAP_PHASE, STEP, 202 COMMAND, GATEWAY > >, where ODAP_PHASE corresponds to the current 203 phase of ODAP, STEP corresponds to a monotonically increasing 204 integer, COMMAND to the command type being issued by a set of 205 gateways (GATEWAY). Figure 1 depicts a high-level view of ODAP$'s 206 phase 1, through its several steps, involving G1 and G2. For 207 simplicity, we omit the ODAP_PHASE, STEP and GATEWAYS field. The ACP 208 exchanges messages to assure atomicity while recording every 209 operation via the log primitive. However, both two-phase commit and 210 three-phase commit can block in case nodes fail. The protocol being 211 blocking means that if the coordinator crashes, then gateways may not 212 finish transactions. When a crash happens, gateways will be waiting 213 for a confirmation/abort, and possibly holding the lock regarding a 214 specific digital asset. 216 3.2. Crash Recovery Model 218 We assume gateways fail by crashing, i.e., by becoming silent, not 219 arbitrary or Byzantine faults. We assume authenticated reliable 220 channels obtained using TLS/HTTPS [TLS]. To recover from these 221 crashes, gateways store in persistent storage data about the step of 222 their protocol. This allows the system to recover by getting from 223 the log the first step that may have failed. We consider two 224 recovery models: 226 o Self-healing mode: assumes that after a crash, a gateway 227 eventually recovers; 229 o Primary-backup mode: assumes that after a crash, a gateway may 230 never recover, but that this failure can be detected by timeout 231 [AD76]. 233 In Self-healing mode, when a gateway restarts after a crash, it reads 234 the state from the log and continues executing the protocol from that 235 point on. We assume the gateway does not lose its long-term keys 236 (public-private key pair) and can reestablish all TLS connections. 238 In Primary-backup mode, we assume that after a period T of the 239 primary gateway failure, a backup gateway detects that failure 240 unequivocally and takes the role of the primary gateway. The failure 241 is detected using heartbeat messages and a conservative value for T. 242 The backup gateway does virtually the same as the gateway in self- 243 healing mode: reads the log and continues the process. The 244 difference is that the log must be shared between the primary and the 245 backup gateways. If there is more than one backup, a leader-election 246 protocol may be executed to decide which backup will take the primary 247 role. 249 3.3. Recovery Procedure 251 Gateways can crash at several points of the protocol. 253 In 2PC and 3PC, recovery requires that the protocol steps are 254 recorded in a log immediately before sending a message and 255 immediately after receiving a message. Thus, at every step k of the 256 protocol, each gateway writes in the log entry indicating its current 257 state. When a node crashes: 259 o Self-healing mode: the recovered gateway informs the other party 260 of its recovery and continues the protocol execution; 262 o Primary-backup mode: if a node is crashed indefinitely, a backup 263 is spun off, using the log storage API to retrieve the most recent 264 version of the log. 266 Upon recovery, the recovered node attempts to retrieve the most 267 recent log of operations. Based on the latest log entry last(log), 268 it derives the current state of the asset transfer. This can be 269 confirmed by querying all other nodes involved in such transfer by 270 sending a recovery message rm. After the current state is fetched 271 and agreed upon by all parties, the ODAP protocol continues. There 272 are several situations when a crash may occur. The first one is 273 immediately after starting the transfer, as shown below: 275 ,--. ,--. ,-------. 276 |G1| |G2| |Log API| 277 `--' `--' `-------' 278 | 1: [1]: writeLogEntry GR)>| 279 | ------------------------------------------------------> 280 | | | 281 |----. | | 282 | | [2] Crash | | 283 |<---' ... | | 284 | [3]recover | | 285 | | | 286 | | | 287 | [4] | | 288 | --------------------------> | 289 | | | 290 | | [5] getLogEntry(i) | 291 | | --------------------------> 292 | | | 293 | | [6] logEntries | 294 | | <- - - - - - - - - - - - - 295 | | | 296 | [7] send updated log ul | | 297 | <-------------------------- | 298 | | | 299 |----. | | 300 | | [8] process log | | 301 |<---' | | 302 | | | 303 | [9] updateLog(ul) | 304 | ------------------------------------------------------> 305 | | | 306 | [10] confirm recovery | | 307 | --------------------------> | 308 | | | 309 | [11] acknowledge recovery| | 310 | <- - - - - - - - - - - - - | 311 | | | 312 | [12]: GR)> | 313 | ------------------------------------------------------> 314 ,--. ,--. ,-------. 315 |G1| |G2| |Log API| 316 `--' `--' `-------' 318 Figure 2 320 The source gateway crashes right before it issued a command to G2 (in 321 this case, init). The gateway eventually recovers in self-healing 322 mode, querying the last log entry from the log storage API. After 323 that, it sends a recovery message to G2, advertising that the 324 recovery has been completed and asking for an updated version of the 325 log, i.e., the current state. In this case, the latest version of 326 the log corresponds to G1?s log. After synchronization has been 327 achieved, the process can continue. 329 The second scenario requires further synchronization (Figure 3). 330 Some fields have been omitted for simplicity. At the retrieval of 331 the latest log entry, G1 notices its log is outdated. It updates it 332 upon necessary validation and then communicates its recovery to G2. 333 The process then continues as defined. 335 ,--. ,--. ,-------. 336 |G1| |G2| |Log API| 337 `--' `--' `-------' 338 | 1: [1]: writeLogEntry init-validate | 339 | -----------------------------------------------------------> 340 | | | 341 | [2]: initiate ODAP's phase 1| | 342 | ----------------------------> | 343 | | | 344 |----. | | 345 | | [3] Crash | | 346 |<---' | | 347 | | | 348 | | [4]: writeLogEntry init | 349 | | -----------------------------> 350 | | | 351 | |----. 352 | | | [5]: execute init from p1 353 | |<---' 354 | | | 355 | | [6]: writeLogEntry done-init | 356 | | -----------------------------> 357 | | | 358 | | [7]: writeLogEntry ack-init | 359 | | -----------------------------> 360 | | | 361 | [8] | | 362 | ----------------------------> | 363 | | | 364 | | [9] getLogEntry(i) | 365 | | -----------------------------> 366 | | | 367 | | [10] logEntries | 368 | | <- - - - - - - - - - - - - - - 369 | | | 370 | [11] send updated log ul | | 371 | <---------------------------- | 372 | | | 373 |----. | | 374 | | [12] process log | | 375 |<---' | | 376 | | | 377 | [13] updateLog(ul) | 378 | -----------------------------------------------------------> 379 | | | 380 | [14] confirm recovery | | 381 | ----------------------------> | 382 | | | 383 | [15] acknowledge recovery | | 384 | <- - - - - - - - - - - - - - | 385 | | | 386 | [16]: init-validateNext | 387 | -----------------------------------------------------------> 388 ,--. ,--. ,-------. 389 |G1| |G2| |Log API| 390 `--' `--' `-------' 392 Figure 3 394 3.4. Log Storage 396 Log primitives are translated into log entries, persisted by the log 397 storage API in the format < operation, step, phase, gateways >, where 398 the gateway issuing the operation is implicit. For example, when G1 399 initiates the operation log(init, n, k, G2), a log entry specifying 400 the command init given to G2, in the nth phase of the phase k is 401 translated to a log entry. After that, the log entry is persisted 402 via the log storage API. Thus, log primitives are also translated 403 into log storage API requests. 405 We consider the log file to be a stack of log entries. Each time a 406 log entry is added, it goes to the top of the stack (the highest 407 index). Logs can be saved locally (computer?s disk), in an external 408 service (e.g., cloud storage service), or in the DLT the gateway is 409 operating. Saving logs locally is faster than saving them on the 410 respective ledger but delivers weaker integrity and availability 411 guarantees. Saving log entries on a DLT may slow down the protocol 412 because issuing a transaction is several orders of magnitude slower 413 than writing on disk or accessing a cloud service. Self-healing mode 414 is compatible with the three types of logs, but Primary-backup mode 415 requires storage in an external service or the DLT. 417 If logs are stored in an external service, security is an issue. We 418 assume the storage service used provides the means necessary to 419 assure the logs' confidentiality and integrity, stored and in 420 transit. The service must provide an authentication and 421 authorization scheme, e.g., based on OAuth and OIDC [OIDC], and use 422 secure channels based on TLS/HTTPS [TLS]. 424 We consider a log storage API that allows developers to abstract from 425 the storage details (e.g., relational vs. non-relational, local vs. 426 cloud) and handles access control if needed. This is API-TYPE 1, as 427 the gateway uses it to store off-chain resources. 429 LOG STORAGE API TABLE 431 4. Format of log entries 433 The log entries are stored by a gateway in its log. Entries account 434 for the current status of one of the three ODAP flows: Transfer 435 Initiation flow, Lock-Evidence flow, and Commitment Establishment 436 flow. The recommended format for log entries is JSON [xxx], with 437 protocol-specific mandatory fields, support for a free format field 438 for plaintext or encrypted payloads directed at the DLT gateway or an 439 underlying DLT. Although the recommended format is JSON, other 440 formats can be used (e.g., XML). 442 The mandatory fields of a log entry are: 444 o Session ID: unique identifier (UUIDv2) representing an ODAP 445 interaction (corresponding to a particular flow) 447 o Sequence Number: represents the ordering of steps recorded on the 448 log for a particular session 450 o ODAP Phase ID: flow to which the logging refers to. Can be 451 Transfer Initiation flow, Lock-Evidence flow, and Commitment 452 Establishment flow. 454 o Source Gateway ID: the public key of the gateway initiating a 455 transfer 457 o Source DLT ID: the ID of the gateway initiating a transfer 459 o Recipient Gateway ID: the public key of the gateway involved in a 460 transfer 462 o Recipient DLT ID: the ID of the gateway involved in a transfer 463 o Timestamp: timestamp referring to when the log entry was generated 464 (UNIX format) 466 o Payload: Message payload. Contains subfields Votes (optional), 467 Msg, Message type. Votes refers to the votes parties need to 468 commit in the 2PC. Msg is the content of the log entry. Message 469 type refers to the different logging actions (e.g., command, 470 backup). 472 o Payload Hash: hash of the current message payload 474 Optional log entry fields are: 476 o Logging profile: contains the profile regarding the logging 477 procedure. If not present, a local store for the logs is assumed. 479 o Source Gateway UID: the uid of the gateway initiating a transfer 481 o Recipient Gateway UID: the uid of the gateway involved in a 482 transfer 484 o Message Digest: Gateway EDCSA signature over the log entry 486 o Last Log Entry: Hash of previous log entry 488 o Access Control Profile: the profile regarding the confidentiality 489 of the log entries being stored 491 Example of a log entry created by G1, corresponding to locking an 492 asset (phase 2.3 of the ODAP protocol) : 494 { 495 "sessionId": "4eb424c8-aead-4e9e-a321-a160ac3909ac", 496 "seqNumber": 6, 497 "phaseId": "lock", 498 "sourceGatewayId": "5.47.165.186", 499 "sourceDltId": "Hyperledger-Fabric-JusticeChain", 500 "targetGatewayId": "192.47.113.116", 501 "targetDltId": "Ethereum", 502 "timestamp": "1606157330", 503 "payload": { 504 "messageType": "2pc-log", 505 "message": "LOCK_ASSET", 506 "votes": "none" 507 }, 508 "payloadHash": "80BCF1C7421E98B097264D1C6F1A514576D6C9F4EF04955FA3AEF1C0664B34E3", 509 "logEntryHash": "[...]" 510 } 512 Figure 4 514 Example of a log entry created by G2, acknowledging G1 locking an 515 asset (phase 2.4 of the ODAP protocol) : 517 { 518 "sessionId": "4eb424c8-aead-4e9e-a321-a160ac3909ac", 519 "seqNumber": 7, 520 "phaseId": "lock", 521 "sourceGatewayId": "5.47.165.186", 522 "sourceDltId": "Hyperledger-Fabric-JusticeChain", 523 "targetGatewayId": "192.47.113.116", 524 "targetDltId": "Ethereum", 525 "timestamp": "1606157333", 526 "payload": { 527 "messageType": "2pc-log", 528 "message": "LOCK_ASSET_ACK", 529 "votes": "none" 530 } 531 , 532 "payloadHash": "84DA7C54F12CE74680778C22DAE37AEBD60461F76D381D3CD855B0713BB98D1", 533 "logEntryHash": "[...]" 534 } 536 Figure 5 538 5. Security Considerations 540 We assume a trusted, secure communication channel between gateways 541 (i.e., messages cannot be spoofed and/or altered by an adversary) 542 using TLS 1.3 or higher. Clients support ?acceptable? credential 543 schemes such as OAuth2.0. 545 The present protocol is crash fault-tolerant, meaning that it handles 546 gateways that crash for several reasons (e.g., power outage). The 547 present protocol does not support Byzantine faults, where gateways 548 can behave arbitrarily (including being malicious). This implies 549 that both gateways are considered trusted. We assume logs are not 550 tampered with or lost. 552 Log entries need integrity, availability, and confidentiality 553 guarantees, as they are an attractive point of attack [BVC19]. Every 554 log entry contains a hash of its payload for guaranteeing integrity. 555 If extra guarantees are needed (e.g., non-repudiation), a log entry 556 might be signed by its creator. Availability is guaranteed by the 557 usage of the log storage API that connects a gateway to a dependable 558 storage (local, external, or DLT-based). Each underlying storage 559 provides different guarantees. Access control can be enforced via 560 the access control profile that each log can have associated with, 561 i.e., the profile can be resolved, indicating who can access the log 562 entry in which condition. Access control profiles can be implemented 563 with access control lists for simple authorization. The 564 authentication of the entities accessing the logs is done at the Log 565 Storage API level (e.g., username+password authentication in local 566 storage vs. blockchain-based access control in a DLT). 568 For extra guarantees, the nodes running the log storage API (or the 569 gateway nodes themselves) can be protected by hardening technologies 570 such as Intel SGX [CD16]. 572 6. References 574 6.1. Normative References 576 [ODAP] Hargreaves, M. and T. Hardjono, "Open Digital Asset 577 Protocol, October 2020, IETF, draft-hargreaves-odap-00.", 578 October 2020, 579 . 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, 583 DOI 10.17487/RFC2119, March 1997, 584 . 586 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 587 Version 1.3?, RFC 8446.", 2018, 588 . 590 6.2. Informative References 592 [AD76] Alsberg, P. and D. Day, "A principle for resilient sharing 593 of distributed resources. In Proc. of the 2nd Int. Conf. 594 on Software Engineering", 1976, <978-0-201-10715-9>. 596 [BHG87] Bernstein, P., Hadzilacos, V., and N. Goodman, 597 "Concurrency Control and Recovery in Database Systems, 598 Chapter 7. Addison Wesley Publishing Company", 1987, 599 . 601 [BVC19] Belchior, R., Vasconcelos, A., and M. Correia, "Towards 602 Secure, Decentralized, and Automatic Audits with 603 Blockchain. European Conference on Information Systems", 604 2019, . 606 [Clar88] Clark, D., "The Design Philosophy of the DARPA Internet 607 Protocols, ACM Computer Communication Review, Proc SIGCOMM 608 88, vol. 18, no. 4, pp. 106-114", August 1988. 610 [HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted 611 Computing Base for Blockchain Infrastructure Security, 612 Frontiers Journal, Special Issue on Blockchain Technology, 613 Vol. 2, No. 24", December 2019, 614 . 616 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 617 C. Mortimore, "OpenID Connect Core 1.0", 2014, 618 . 620 [SRC84] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 621 in System Design, ACM Transactions on Computer Systems, 622 vol. 2, no. 4, pp. 277-288", November 1984. 624 Authors' Addresses 626 Rafael Belchior 627 INESC-ID, Instituto Superior Tecnico 629 Email: rafael.belchior@tecnico.ulisboa.pt 630 Miguel Correia 631 INESC-ID, Instituto Superior Tecnico 633 Email: miguel.p.correia@tecnico.ulisboa.pt 635 Thomas Hardjono 636 MIT 638 Email: hardjono@mit.edu