[Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (8 June 2021)

[Thomas Hardjono <[e-mail]>]

Folks,

Here are the summary notes from yesterday's meeting.

As usual, please jump in to make corrections.


-- thomas --


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

Date: Tuesday 8 June 2021.

(a) Attendees:

Denis Avrilionis
Shiping Chen
Claire Facer
Martin Hargreaves
Luke Riley
Tom McGary
Michael McBride
John Robotham
Java Xu
Thomas Hardjono


(b) IETF Note Well slide

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


(c) Gateway identification & discovery (Shiping/Thomas)

-- The gateway identification draft-00 has just been uploaded

-- URL is:  https://www.ietf.org/archive/id/draft-chen-dlt-gateway-identification-00.txt

-- The two figures are still blank, and will be added in the next revision.

-- Currently the draft discusses two basic options, namely identification/discovery at the Application Layer and Network Layer.

-- At the application layer, the driving function is the business agreement (peering agreement or contract) between two VASPs or a group of VASPs (e.g. consortium).

-- The information regarding the gateways  (i.e. gateway identifier, VASP owner, public keys & certs, etc.) could be placed in a "directory" (or list) that is shared by the VASPs. This is similar in approach to that being taken by the TRISA community (Travel Rule Information Sharing Architecture).

-- Regardless of the form of information representation (e.g. directory, list, blockchain, etc.) there is the question of access/permissions on the directory.  

-- The directory could be (should be) publicly-readable but there may be cases where members of a private decentralized ledger network (DLN) may wish for this information to be read-protected in a private directory.

-- The network layer approach was discussed at last meeting (inspired by the SMTP/MTA  model).  This approach could be combined with the directory strategy, where gateways can validate the information of peer gateways by querying the directory.

-- Tom noted that the use of the “client/wallet” in the diagram may confuse some people, because there are cases where the Originator (Alice) is the wallet-holder but there are also cases where there is a third party Wallet Provider.

-- Martin suggested that instead of “client/wallet”, simply use the term “Originator”. Shiping agrees about the potential for confusion, and will use that term in the next revision. Thomas noted that the interaction between the Originator and the Gateway in a DLN is out of scope for this draft. Basically, the draft focuses only on G1 finding G2.


-- Other ideas:  Resource PKI (RFC6480).  Mike explains that RPKI is used commonly for an AS (autonomous system, such as an ISP) to claim prefix number for blocks of IP addresses that it owns (i.e. has been assigned to it). 

-- RPKI runs out-of-band from the BGP protocol. This allows ISPs to share Route Origination Authorization (ROA), permitting one ISP to validate a claim made another ISP that it owns a given prefix. ISPs can use RPKI to prevent hijacking of prefixes by other claimants.

-- Mike continued to explain that RPKI is somewhat tied to the BGP paradigm, and so some enterprises that wish to deploy the gateway-to-gateway approach (i.e. in the draft) may not be interested in the RPKI approach.

-- Thomas asks if there was some way to “modify” RPKI to carry gateway information. Mike says it’s a big effort, but technically speaking some fields can be added. Tom mentioned that a key goal of RPKI is for an AS to assert who they say they are, and so RPKI is not so much a “discovery” mechanism but an assertion mechanism.

-- Tom suggested that the RPKI and DNSSEC should be requirements for infrastructures underlying DLNs, and thus should be mentioned in the Security Considerations section.

-- Question from Martin: in this scenario what is a gateway asserting ownership of? Tom mentions that the gateway could claim ownership of IP address (i.e. VASP owns IP address).  Martin mentions that we assume gateways will be running on top of TCP/IP, and so could assume that at the BGP layer constructs (such as RPKI and ROA flows) are already running. But the BGP and RPKI paradigm is useful to explain the gateway architecture bottom to top (i.e. to application layer where the service endpoints reside).

-- The group also discussed mechanism to identity DLNs (entire network), and how to address cases where a gateway is dual-headed in that it is participating in two separate DLNs.  Mike mentioned perhaps we need to think of some numbering scheme for DLNs. More discussion and thinking needed.



(d) Other gateway identification mechanisms (e.g. D-PKI and DIDs).

-- Thomas gave an example of the W3C DID (Decentralized Identifier) structure and VC (Verified Credential), asking if a DID could be used by a VASP to declare (self-register) its gateways.  For example, each gateway could have its own DID data structure published on the blockchain by its owner/VASP. Thus, for all the gateways belonging to a VASP, the VASP would sign the DID data structure recorded on the blockchain.

-- However, since each gateway is a unique device (all bearing the same standard ODAP service endpoint) the endpoint public-key in each DID would be different public-keys. For a given gateway, the endpoint public-key in its DID could be used to establish the TLS secure channel to that gateway.

-- Martin commented that a core issue with DIDs lies with the “roots of trust” in the entity declaring the DID (because a rogue entity could self-declare its fake gateway using the DID mechanism). This means that the VASP signing public-key has to be chained under a well-known entity such as CA in the traditional PKI model. This also why there are EV certificates that carry legal and business information regarding the VASP.

-- Thomas briefly describe the Verifiable Credential (VC) example, where the claim section carries the assertion (attribute) regarding the entity (id) whose public-key is stated in the VC data structure.



(e) Other items: 

-- The group will take a break in July (i.e.  no meetings for July).

-- Thomas will send calendar cancellations for July.

-- After July, the first August meeting will be on Tuesday August 3rd.


(f) Next meeting in June: 

-- June 22nd.

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