Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (11 May 2021)

From: Thomas Hardjono <[email-masked]>
Date: Thu, 13 May 2021 13:25:36 +0000

Folks,

We had a lively discussion yesterday with regards to Phase-1 and the various things that need to happen in this phase.

I've taken some short notes based on memory (apologies if I forgot some items).  Please jump in and add/correct.

-- thomas --

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

Date: Tuesday 11 May, 2021

(a) Attendees:

Denis Avrilionis
John Robotham
Martin Hargreaves
Gilbert Verdian
Mizan Chowdhury
Clair Facer
Juan Ignacio Ibanez
Thomas Hardjono

(b) IETF Note Well slide

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

(c) Meeting time:

-- We will continue our bi-weekly meetings following the UK/EU/US timezone.

-- 7am US-Pacific / 10am US-East / 3pm UK-Lisbon / 11pm Tokyo / 12midnight Sydney.

(d) Updates on ODAP (Thomas):

-- The ODAP draft has just been updated (now draft-02), with material in Section 6 to 8.

-- Section 6 covers Phase-1, section 7 covers Phase-2 and section 8 covers Phase-3.

-- As can be seen from the draft, Section 6 is still sparse because Phase-1 is turning out to involve quite a number of complex tasks.

(e) Discussion about tasks/function in Phase-1 (i.e. preparation phase):

-- It seems useful to categorize or group the tasks in Phase-1 into (a) gateway verification at the network layer; (b) gateway ownership verification (i.e. identity of VASP who owns it); (c) legal status of the VASP in the jurisdiction of operations.

-- At the network layer, we are addressing the problem via the work from Shiping on gateway discovery etc.

-- At the ownership level, one straightforward way would be to use X.509 certificates (which will also be needed for the TLS session between the gateways).

-- Thomas mentioned that the SWIFT Banking community employs X.509 certs and have Cert Profiles.  Martin concurs. Gilbert mentioned that there are also effort to look at a decentralized PKI (DPKI), using blockchains/DLTs.

-- Denis brought-up the question about auditability and responsibility. The hierarchical certificate arrangement, the responsibility ultimately stops at one entity that must own the responsibility.  

-- Denis also mentioned the European Blockchain Services Infrastructure (EBSI) project, that consists of multiple EU nations and where there is a need to identify public organizations ( e.g. government) belonging to each EU member nation.

-- Thomas mentioned that the closest analogy would be the US Federal PKI efforts, where each gov department has its own certificate hierarchy and where some certificate cross-signing (e.g. Bridge CA model) is used ensure PKI interoperability.

-- Denis also mentioned that in Phase-1 there needs to be the ability to verify the digital asset (i.e. legal status) that is being transacted. This is important in the EU EBSI project because different member nations may have different national-level regulations regarding a given digital asset.

-- John mentioned that asset movement tracking is also important from the taxation perspective, including from the audit and reconciliation requirements.  There is also the question around privacy and GDPR if identification information is either directly present on the ledger, or if it can be correlated or derived from data on the ledger.

(f) Next meeting is 25 May 2021.

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

---

From: Rafael Belchior <[email-masked]>
Date: Thu, 13 May 2021 22:12:35 +0100

Thomas and All,
Thank you for the notes.

I'll comment inline:

A 2021-05-13 14:25, Thomas Hardjono escreveu:
> Folks,
> 
> We had a lively discussion yesterday with regards to Phase-1 and the
> various things that need to happen in this phase.
> 
> I've taken some short notes based on memory (apologies if I forgot
> some items).  Please jump in and add/correct.
> 
> 
> -- thomas --
> 
> -- As can be seen from the draft, Section 6 is still sparse because
> Phase-1 is turning out to involve quite a number of complex tasks.
> 
> 
> -- It seems useful to categorize or group the tasks in Phase-1 into
> (a) gateway verification at the network layer; (b) gateway ownership
> verification (i.e. identity of VASP who owns it); (c) legal status of
> the VASP in the jurisdiction of operations.

Regarding b), should we consider attestation endorsements?
I think we also ought to define the logging profile / decentralized 
storage in this phase.

> -- At the ownership level, one straightforward way would be to use
> X.509 certificates (which will also be needed for the TLS session
> between the gateways).
> 
> -- Thomas mentioned that the SWIFT Banking community employs X.509
> certs and have Cert Profiles.  Martin concurs. Gilbert mentioned that
> there are also effort to look at a decentralized PKI (DPKI), using
> blockchains/DLTs.
> 
> -- Denis brought-up the question about auditability and
> responsibility. The hierarchical certificate arrangement, the
> responsibility ultimately stops at one entity that must own the
> responsibility.
> 
> -- Denis also mentioned the European Blockchain Services
> Infrastructure (EBSI) project, that consists of multiple EU nations
> and where there is a need to identify public organizations ( e.g.
> government) belonging to each EU member nation.
> 

> -- Thomas mentioned that the closest analogy would be the US Federal
> PKI efforts, where each gov department has its own certificate
> hierarchy and where some certificate cross-signing (e.g. Bridge CA
> model) is used ensure PKI interoperability.
> 
> -- Denis also mentioned that in Phase-1 there needs to be the ability
> to verify the digital asset (i.e. legal status) that is being
> transacted. This is important in the EU EBSI project because different
> member nations may have different national-level regulations regarding
> a given digital asset.

I think not necessarily. If a payment channel is opened and several 
assets are traded after, then that verification might occur in the 
second phase.

The EBSI is mainly directed to governments (vs companies), correct? What 
is the connection between gateway-to-gateway cross-jurisdiction 
transfers and the EBSI?

> 
> -- John mentioned that asset movement tracking is also important from
> the taxation perspective, including from the audit and reconciliation
> requirements.  There is also the question around privacy and GDPR if
> identification information is either directly present on the ledger,
> or if it can be correlated or derived from data on the ledger.
> 

It is possible, in principle, to redact data from a Hyperledger Fabric 
ledger (paper Redacting Transactions from
Execute-Order-Validate Blockchains from ICBC2021). Private data could 
also be used - this would ensure better compliance with GDPR.

Cheers,
Rafael

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 13 May 2021 22:49:12 +0000

Thanks Rafael,

>>> I think we also ought to define the logging profile / decentralized

Yes, I think we need to add device attestations - which allows gateways to report their system stack, hardware configuration, and key configuration.

Currently the RATS WG (Remote ATtestation ProcedureS) has just finalized their Attestation Architecture draft-v12 (which BTW follows closely from the TCG's model):

https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

In certain blockchain Consortium use-cases, there might be some minimal device configuration that may be mandated by the Consortium membership rules. This means that there may be some kind of "attested device profile" that lists permissible device configurations.

>>> is the connection between gateway-to-gateway cross-jurisdiction

My understanding is that currently EBSI is developed for the public sector (correct me, Denis) -- which may include national banks.

So the question arises with regards to *asset definitions* that may be:  (a) EU-wide and (b) per-country (member of the EU).  

So for example, a stablecoin that is pegged 1-to-1 to the Euro may be an acceptable digital asset to all EU nations.  However, a digital promissory note from Germany (say) may be acceptable in a subset of the EU nations.

In this configuration, it is possible that each bank will have one or more gateways that interfaces with the EBSI blockchain network.

So when an originator in Germany sends a digital promissory note (via its gateway G1) to a beneficiary in say Portugal, the gateway G2 in Portugal will need to verify that the local regulations in Portugal permits in-take of the German promissory note.

>>> also be used - this would ensure better compliance with GDPR.

Another model may be the simple "notary blockchain" (also called the "witness blockchain") which just carries the hashes in the ledger entries, without any economic value to the hashes or blocks. This is like the original hash-chain design from Haber/Stornetta in 1993.

Here all the relevant data is kept off-chain. Only the transacting parties know the relevance of the hash values on-chain in the ledger (and can point to them in case of disputes).

For those who are interested, here is a link to the IEEE ICBC2021 Redacting Transactions paper from a couple of weeks ago: 

https://bit.ly/3tPbHLQ

-- thomas --