Re: [Blockchain-interop] Charter discussion

Hi,

The proposal is fully inline with what we have been discussing, so I fully agree.

A few details:
- Should we include the draft-belchior-… in the list of drafts?
- When you mention TLS, does it make sense to mention also OpenID Connect?
- When you say "on the classic 2-Phase Commit (2PC or 3PC) design”, we could generalize a bit to “on an atomic commit protocol (e.g., 2PC)”

Best,
Miguel

> On 6 Jan 2021, at 14:39, Thomas Hardjono <hardjono@mit.edu> wrote:
> 
> 
> Folks,
> 
> It would be great if we could start a Charter discussion so that we can have a draft charter going into IETF110 in the first week of March.
> 
> Below is a draft text that is basically taken from our slides at the previous IETF109 SecDispatch.
> 
> https://datatracker.ietf.org/meeting/109/materials/slides-109-secdispatch-draft-hardjono-blockchain-interop-arch-00
> 
> The charter needs to be tight enough that we can deliver within time (e.g. deliver the 3 drafts by end of 2021).
> 
> Looking for your inputs.
> 
> ---------------------------
> 
> Proposed name:  DLT Gateway Protocol (DGP)
> 
> The goal of DGP is to develop a gateway-to-gateway protocol for virtual asset transfers between distributed ledger technology (DLT) systems.
> 
> The gateway protocol must support the unidirectional secure transfer of  the digital representation of an asset between two gateways fronting DLTs, satisfying requirements of atomicity and non-repudiation, and agnostic to the higher-layer economic value of the asset. It must support cases where one or both DLT systems behind the gateways are private (where the interior resources are not externally accessible). Additionally, APIs defined must support cases where one gateway is fronting a Legacy system.
> 
> The gateway protocol must satisfy the well-known ACID properties. Atomicity: a transfer must either commit or entirely fail (failure means no change to asset ownership). Consistency: a transfer (commit or fail) must always result in the asset located in one DLT only. Isolation: while a transfer is occurring, the asset ownership cannot be modified (no double-spend). Durability: once a transfer is committed, it must remain so regardless of subsequent gateway crashes.
> 
> The gateway protocol will be based on the classic 2-Phase Commit (2PC or 3PC) design.  The interaction channel between the APIs endpoints at the gateways is assumed to be protected using TLS1.2 (TLS1.3).
> 
> Proposed Deliverables (2021):
> -- Architecture document	
> -- Gateway protocol document defining APIs and endpoint definitions (ODAP)
> -- Use-cases & Requirements document
> 
> Optional:
> -- Asset Profile JSON specification
> -- Log-metadata JSON specification (crash recovery)
> 
> Existing drafts:
> -- draft-hardjono-blockchain-interop-arch-01 
> -- draft-hargreaves-odap-01 
> -- draft-sardon-blockchain-gateways-usecases-00
> -- draft-sardon-blockchain-interop-asset-profile-00
> 
> 
> Out of scope:
> -- Blockchains and DLT systems
> -- Consensus & BFT protocols, PoW, PoS, etc.
> -- Cryptocurrencies, tokenization, etc.
> -- Incentive mechanisms, economic models; etc.
> -- Zero-knowledge proof (ZKP) protocols
> -- Authentication & Authorization protocols
> -- Concurrency control algorithms
> -- Identity management & privacy, etc. etc.
> 
> 
> ---------------------------
> 
> 
> Best
> 
> 
> -- thomas --
> 
> 
> -- 
> Blockchain-interop mailing list
> Blockchain-interop@ietf.org
> https://www.ietf.org/mailman/listinfo/blockchain-interop