[Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (27 April 2021)

[Thomas Hardjono <[e-mail]>]

Folks,

Here are my short notes from the meeting yesterday.

Please feel free to jump in and correct these notes, and perhaps even expand and discuss further on the list.


-- thomas --

----------------------------------------------
Summary Notes from IETF Blockchain Gateway Interoperability group meeting

Date: Tuesday 27 April, 2021

(a) Attendees:

Denis Avrilionis
John Robotham
Luke Riley
Martin Hargreaves
Gilbert Verdian
Mizan Chowdhury
Rafael Belchior
Miguel Correia
Clair Facer
Himank Gupta
Java Xu
Juan Ignacio Ibanez
Tom McGarry
Shiping Chen
Thomas Hardjono


(b) IETF Note Well slide

-- This group meeting operates under IETF IP Rules as described in RFC5378 and RFC8179.


(c) Administrative notes regarding time-zone of future meetings:

-- Given that the majority of the regular attendees and draft contributors are based in the Northern Hemisphere, the group agreed to move all meetings to the UK/EU/US time

-- During the current season, this means 7am US-Pacific / 10am US-East / 3pm UK-Lisbon / 11pm Tokyo / 12midnight Sydney.

-- Thank you to the folks in APAC for their willingness to stay up so late.


(d) Updates on Crash Recovery (Rafael):

-- Rafael presented on the updates regarding the crash recovery information needed for the 2PC protocol, which in this  case in the ODAP protocol.

-- The Source gateway and Recipient gateway must maintain logs of the payloads of messages which they exchange with each other.

-- There are several items of information that must be logged (referred to as the ODAP Payload). This includes:

   o The ODAP protocol version, session-ID (UUIDv2), message sequence number, the (current) ODAP-Phase-number, Resource-URL, POST/GET action and responses, etc.

   o  Credential profile type, Credential block (actual token, cert, string), Payload profile (i.e. asset profile), Application profile, the POST message payload, hash of the payload, digital signature.

-- Then there is also the issue of the Log Format and the attributes that relate to the entities (timestamp, pubkey of source gateway G1, pubkey of source destination G2, ID of the DLTs).

-- There are several options has to the form/profile and location of the logs. Each gateway should retain its own copy of the logs. 

-- However, there is also the possibility of employing a third-party blockchain-based solution (or cloud solutions), where both Gateway can write/append to that shared log. 

-- The entries to this shared-log must observer data privacy requirements (e.g. GDPR), and could in fact consists primarily of hashes of the entries of the full log (held locally by each gateway).

-- This shared-log approach could be useful in cases of dispute resolution, where an authorized Audit entities could be given read-access to the relevant entries in the shared-log. Alternatively, the Shared Log could be a publicly-readable blockchain.

-- Finally, the above negotiation of the crash recovery parameters and log profile must occur early in Phase-1 of the architecture.


(e) Updates on Gateway Discovery (Shiping/Thomas):

-- The work on the gateway discovery/look-up has done a full circle to where we started from, namely a simple discovery architecture based on the existing DNS infrastructure.

-- For inspiration, the gateway discovery architecture looked at the SMTP protocol based on the MTA model (Message Transfer Agent).

-- In the MTA model, the MTA in the origin domain uses the FQDN (domain name portion) of the destination email address to query the DNS for the IP address of the MTA in the destination domain. The IP address of the MTA servers is held in the MX-Record in the DNS.

-- We could use the same look-up model, by using the relevant entries in the DNS Records to help locate the destination gateway.

-- Martin mention that we don't necessarily need a new type of DNS record, and the information could just be added to the TXT Record in the domain. Tom McGary also concurred, that defining a new record will be difficult (painful).

-- Martin also points to the ODAP draft that already lists the identity of the gateways: see Section 5.3. and Section 5.4 of the ODAP draft-01.


(f) Next meeting is 11 May 2021.


------------------------------------