Subject: [Blockchain-interop] FW: New Version Notification for draft-chen-dlt-gateway-identification-00.txt

From: Thomas Hardjono <[email-masked]>
Date: Mon, 7 Jun 2021 14:52:36 +0000

Folks,

Here is a first-cut rough draft of the Gateway Identification & Discovery work.

A couple of the diagrams are still missing, but will be added in the next revision.

Best

Shiping & Thomas

________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, June 7, 2021 10:49 AM
To: Shiping Chen; Thomas Hardjono
Subject: New Version Notification for draft-chen-dlt-gateway-identification-00.txt

A new version of I-D, draft-chen-dlt-gateway-identification-00.txt
has been successfully submitted by Thomas Hardjono and posted to the
IETF repository.

Name:           draft-chen-dlt-gateway-identification
Revision:       00
Title:          Gateway Identification and Discovery for Decentralized Ledger Networks
Document date:  2021-06-08
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-chen-dlt-gateway-identification-00.txt
Status:         https://datatracker.ietf.org/doc/draft-chen-dlt-gateway-identification/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-chen-dlt-gateway-identification

Abstract:
   Today there is a growth in the number of blockchain and decentralized
   ledger networks (DLN) around the world, and interoperability across
   different networks represents a challenge for the value proposition
   of these networks.

   One approach for blockchain interoperability to be achieved is to
   employ gateways that permit assets to flow across the relevant
   networks of blockchains.

   However, a core requirement for interoperability is the correct
   identification of computer systems that act as gateways and the
   correct validation of the ownership of the gateway.  A secondary
   requirement is for a gateway to inquire as to the existence of an
   entity address (public key) within a given decentralized ledger
   network.

   This memo discusses options with regards gateway identification and
   verification strategies.  It looks at addressing the problem from the
   application layer and from the network layer.  It also discusses
   other options, such as relying on a third-party blockchain-registered
   identifiers and resolver services

The IETF Secretariat

---

From: Michael McBride <[email-masked]>
Date: Mon, 7 Jun 2021 20:16:17 +0000

Looks good Thomas. 

Since an AS/BGP will be required between gateways (correct? Or only when a BGSP is involved?) we can also leverage RPKI to help ensure the route being announced between gateways is coming from the legitimate route (and subsequent data) owner. 

mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Monday, June 07, 2021 7:53 AM
To: [email-masked]
Subject: [Blockchain-interop] FW: New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Folks,

Best

Shiping & Thomas

A new version of I-D, draft-chen-dlt-gateway-identification-00.txt
has been successfully submitted by Thomas Hardjono and posted to the IETF repository.

Name:           draft-chen-dlt-gateway-identification
Revision:       00
Title:          Gateway Identification and Discovery for Decentralized Ledger Networks
Document date:  2021-06-08
Group:          Individual Submission
Pages:          13
URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;reserved=0
Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;reserved=0

Abstract:

The IETF Secretariat

--
Blockchain-interop mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6FtJXXNd0WfgssWVR%2F3Dc2nCXLiSUjgyo3rKeXCLvqc%3D&amp;reserved=0

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 7 Jun 2021 21:26:40 +0000

Thanks Mike,

RPKI is an good possibility, such as for cases when not all the Gateways (i.e. their IP addresses) are immediately visible from outside the network.

Its certainly an easy way for an asset service provider (i.e. VASP) to declare ownership of a set of IP addresses for the gateways it owns.

Best

--thomas

________________________________________
From: Michael McBride [[email-masked]]
Sent: Monday, June 7, 2021 4:16 PM
To: Thomas Hardjono; [email-masked]
Subject: RE: New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Looks good Thomas.

mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Monday, June 07, 2021 7:53 AM
To: [email-masked]
Subject: [Blockchain-interop] FW: New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Folks,

Best

Shiping & Thomas

Abstract:

The IETF Secretariat

---

From: Rafael Belchior <[email-masked]>
Date: Fri, 18 Jun 2021 12:10:21 +0100

Hello All,

Shipping, Thomas, thanks a lot for putting this together.

A few comments:

" (a) Application layer: At the application layer a gateway
    identification scheme is needed that permits an organization who
    participate in a given DLN to declare (advertise) one or more
    gateways into that DLN.  This permits organizations to establish
    peering agreements (contracts) based on the asset type, DLN and
    jurisdictions, identifying (specifying) the gateways that will be
"

isn't this still on the network layer, since it is relative to the 
participation on a DLN?

On 4.1:
"  (iii) asset type transferability: verification that a remote gateway
    for a destination DLN is mechanically capable to receive the type of
    asset and that legally permitted to receive the type of asset.
"

It looks like this corresponds to ODAP's first phase, on the gateway 
verification. Are we performing this on discovery + ODAP?

On "Depending on the specific technical
    constraints of a given DLN (e.g. consensus model), not every node
    within the DLN may be designated to be a gateway capable of
    participating in an asset transfer between two DLNs.  As such, the
    service provider must nominate its nodes or systems specifically as
    gateways"

I think we should add that gateways may not be DLN nodes but rather 
software components that connect to DLN nodes (e.g., Hyperledger Cactus 
ODAP plugin using a Fabric Connector).

"   To ensure the safety of the transferred digital assets, blockchain
    gateway service providers (BGSP) must be trustworthy to clients who
    use the services.  As a result, they must meet a high standard to
    ensure security and trust at different levels, ranging from business
    to networking, from hardware device to software protocol.
"

Essentially the verification comes up to trust a centralized party?
The problem of verifying if a software component is indeed a gateway is 
deferred to those BGSPs, correct?

Cheers,

A 2021-06-07 22:26, Thomas Hardjono escreveu:
> Thanks Mike,
> 
> RPKI is an good possibility, such as for cases when not all the
> Gateways (i.e. their IP addresses) are immediately visible from
> outside the network.
> 
> Its certainly an easy way for an asset service provider (i.e. VASP) to
> declare ownership of a set of IP addresses for the gateways it owns.
> 
> 
> Best
> 
> --thomas
> 
> Subject: RE: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> Looks good Thomas.
> 
> Since an AS/BGP will be required between gateways (correct? Or only
> when a BGSP is involved?) we can also leverage RPKI to help ensure the
> route being announced between gateways is coming from the legitimate
> route (and subsequent data) owner.
> 
> mike
> 
> Subject: [Blockchain-interop] FW: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> 
> Folks,
> 
> Subject: New Version Notification for
> draft-chen-dlt-gateway-identification-00.txt
> 
> URL:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;reserved=0
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;reserved=0
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;reserved=0
> 
> 
> Abstract:

-- 
-- 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: "Chen, Shiping (Data61, Eveleigh)" <[email-masked]>
Date: Sat, 19 Jun 2021 01:45:25 +0000

Thank Rafael for your comments.

Here are my 2-cents thoughts on your comments, also called comments on comments 😊

>isn't this still on the network layer, since it is relative to the participation on a DLN?

Yes, more preciously it is to bind a DLN to a specific blockchain gateway service/application operated by a specific BGSP.

>It looks like this corresponds to ODAP's first phase, on the gateway verification. Are we performing this on discovery + ODAP?

Except for the offline interactions, all the real-time interactions can be implemented/incorporated into ODAP's phase 1, I guess.

>I think we should add that gateways may not be DLN nodes but rather software components that connect to DLN nodes (e.g., Hyperledger Cactus ODAP plugin using a Fabric Connector).

It is subject to the value of the gateway service business and the corresponding trust requirement.

We can leave it to the BGSP to negotiate each other and configure their gateways as they agree.

>The problem of verifying if a software component is indeed a gateway is deferred to those BGSPs, correct?

Yes, the same answer as the above, i.e. let markets/BGSPs decide which centralized certification party they trust, and what (network/hardware/software) level of certifications required for them to establish their business trust.

Cheers

-

Shiping

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Rafael Belchior
Sent: Friday, 18 June 2021 9:10 PM
To: [email-masked]
Subject: Re: [Blockchain-interop] New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Hello All,

A few comments:

    jurisdictions, identifying (specifying) the gateways that will be "

isn't this still on the network layer, since it is relative to the participation on a DLN?

On 4.1:

"

It looks like this corresponds to ODAP's first phase, on the gateway verification. Are we performing this on discovery + ODAP?

    gateways"

I think we should add that gateways may not be DLN nodes but rather software components that connect to DLN nodes (e.g., Hyperledger Cactus ODAP plugin using a Fabric Connector).

"

The problem of verifying if a software component is indeed a gateway is deferred to those BGSPs, correct?

Cheers,

> To: Thomas Hardjono; [email-masked]<mailto:[email-masked]>

> From: Blockchain-interop <[email-masked]<mailto:[email-masked]>> On

> Behalf Of Thomas Hardjono

> To: [email-masked]<mailto:[email-masked]>

> Here is a first-cut rough draft of the Gateway Identification &

> Discovery work.

> A couple of the diagrams are still missing, but will be added in the

> next revision.

> From: [email-masked]<mailto:[email-masked]> [[email-masked]]

> Title:          Gateway Identification and Discovery for Decentralized

> Ledger Networks

>    Today there is a growth in the number of blockchain and

> decentralized

>    verification strategies.  It looks at addressing the problem from

> the

>    other options, such as relying on a third-party

> blockchain-registered

> [email-masked]<mailto:[email-masked]>

--

-- Rafael Belchior

Lisboa

--

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/blockchain-interop

---

From: Rafael Belchior <[email-masked]>
Date: Sat, 19 Jun 2021 13:37:05 +0100

Hey Shiping, 

Thanks very much for your comments, I am clarified. 

Have an excellent weekend, 

Cheers, 

A 2021-06-19 02:45, Chen, Shiping (Data61, Eveleigh) escreveu:

> _Yes, more preciously it is to bind a DLN to a specific blockchain gateway service/application operated by a specific BGSP. _ 
> 
> _Except for the offline interactions, all the real-time interactions can be implemented/incorporated into ODAP's phase 1, I guess._ 
> 
> _It is subject to the value of the gateway service business and the corresponding trust requirement._ 
> 
> _We can leave it to the BGSP to negotiate each other and configure their gateways as they agree._ 
> 
> _ _ 
> 
> _Yes, the same answer as the above, i.e. let markets/BGSPs decide which centralized certification party they trust, and what (network/hardware/software) level of certifications required for them to establish their business trust._ 
> 
> Cheers 
> 
> - 
> 
> Shiping 
> 
> _ _ 
> 
>> From: Blockchain-interop <[email-masked]> On 
> 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;reserved=0 [1] 
> 
>> Status: 
> 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;reserved=0 [2] 
> 
>> Htmlized: 
> 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;reserved=0 [3] 
> 
>> 
> 
>> 
> 
>> Abstract: 
> 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6FtJXXNd0WfgssWVR%2F3Dc2nCXLiSUjgyo3rKeXCLvqc%3D&amp;reserved=0 [4] 
> 
> -- 
> 
> -- Rafael Belchior 
> 
> https://rafaelapb.github.io/ [5] 
> 
> https://www.linkedin.com/in/rafaelpbelchior/ [6] 
> 
> -- 
> 
> https://www.ietf.org/mailman/listinfo/blockchain-interop [7]

-- 
-- Rafael Belchior 

Links:
------
[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;amp;reserved=0
[2]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;amp;reserved=0
[3]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;amp;reserved=0
[4]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;amp;sdata=6FtJXXNd0WfgssWVR%2F3Dc2nCXLiSUjgyo3rKeXCLvqc%3D&amp;amp;reserved=0
[5] https://rafaelapb.github.io/
[6] https://www.linkedin.com/in/rafaelpbelchior/
[7] https://www.ietf.org/mailman/listinfo/blockchain-interop