﻿<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml2rfc.tools.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-sardon-blockchain-gateways-usecases-03" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->


    <title abbrev="Blockchain Gateways: Use-Cases">Blockchain Gateways: Use-Cases</title>

        <author fullname="Aetienne Sardon" initials="A" surname="Sardon">
      <organization>Swisscom</organization>
      <address>
        <email>Aetienne.Sardon@swisscom.com</email>
      </address>
    </author>
    
    <author fullname="Thomas Hardjono" initials="T" surname="Hardjono">
      <organization>MIT</organization>
      <address>
        <email>hardjono@mit.edu</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>mmcbride@futurewei.com</email>
      </address>
    </author>


    <date day="20" month="April" year="2022"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
	<t>In the past five years there has been a growing interest in using blockchains 
	and DLT systems as a means to create a new mechanism to issue, 
	distribute and manage virtual assets.  
	However, as DLT systems consisting of peer-to-peer (P2P) network of nodes increase in number, 
	there is an increasing need to interconnect these networks to permit virtual assets to flow into and out of them. 
	This document captures a number of use-cases driving the need for interoperability between DLT systems.
</t>
    </abstract>
  </front>


  <middle>


   <section anchor="introduction" title="Introduction">
      <t>In the past five years there has been a growing interest in using 
      blockchains and DLT systems as a means to create a new mechanism to issue, 
      distribute and manage virtual assets.</t>

      <t>However, as DLT systems consisting of peer-to-peer (P2P) network of nodes increase in number, 
      there is an increasing need to interconnect these networks to 
      permit virtual assets to flow into and out of them. </t>

	<t>This document captures a number of use-cases driving the need for interoperability between DLT systems.</t>
	
     </section>
          
   <section anchor="UC1" title="Use-Case: CBDC interoperability">

	<t>A Central Bank Digital Currency (CBDC) is a digital version of 
	the sovereign currency within a nation. 
	The CBDC is distinct from other types of digital currencies 
	because (a) its sole issuer is a central bank, and 
	(b) like paper sovereign currencies the issuance of a CBDC 
	represents a claim that the holder has upon the central bank.</t>
 
	<t>Many central banks are considering the use of DLT systems for CBDCs. 
	For example, the Monetary Authority of Singapore (MAS) and 
	the Bank of Canada (BOC) have been experimenting with private blockchains 
	and have been exploring methods used to settle CBDCs (see project Ubin and Jasper) [MAS19]. 
	Since different central banks might be using different private DLT systems, 
	interoperability of these systems will be crucial for facilitating cross-border payments. </t>


	<t>The MAS and BOC have carried out a joint pilot project in 2019 
	to evaluate how transactions between a Quorum-based 
	and Corda-based systems can be performed [MAS19].  
	While their HTLC based proof-of-concept with direct 
	node-to-node connectivity was conducted successfully, 
	they point out that such a network model may have poor 
	resiliency and suggest testing alternative models, 
	in particular using gateway nodes that would 
	act as service nodes for the network participants.</t>


     </section>


   <section anchor="UC2" title="Use-Case: Application and Data Portability">

	<t>Portability has been described as a desirable property for 
	applications on private blockchains and DLT systems [SKS18].  
	For example, applications with poor portability may suffer 
	from vendor lock-in effects, potentially preventing users 
	to benefit from better middleware platforms. </t>

	<t>Moreover, regulations like the GDPR even explicitly require data portability. 
	For private blockchains, where the network members 
	may be subject to such regulations, interoperability shall be encouraged [STOA19].  
	The use case would be to migrate either the application (e.g. a token smart contract) 
	and/or the associated state (e.g. token balances) from one private blockchain to another.</t>   



     </section>



   <section anchor="UC3" title="Use-Case: Interconnection of Supply-Chains">

	<t>Blockchains and DLT systems are currently being deployed 
	for augmenting the supply-chains of good and services [Scot19]. 
	The notion of a shared ledger has significant appeal among 
	the participants of a supply-chain network (e.g. suppliers, vendors, buyers, etc.) 
	because: (i) it permits all participants with equal visibility into the state of the supply/demand of goods; 
	(ii) permitting suppliers (e.g. manufacturers) to increase 
	their efficiency in maintaining the supply of goods in warehouses, 
	leading to the freeing-up of capital, and 
	(iii) allowing participants to improve the tracking of deliveries and payments settlements.</t>

	<t>A key challenge for of a supply-chain network based on DLT systems 
	is its ability to interoperate with another supply-chain network. 
	Interoperability across blockchains and DLT systems allows a participant 
	(e.g. manufacturer, buyer) to participate at a single end-point in the network, 
	while giving them access to all other blockchains that are connected. 
	Without interoperability, the participant would need to join each 
	and every supply-chain DLT, something that is cumbersome, costly and does not scale.</t>  
	
	<section title="Pharmaceuticals"> 
	<t>The prescription, and vaccination, supply chain involves many partners and includes recording 
	the change of ownership of these medicinal assets. This supply chain also involves tracking 
	data such as the shipping container temperature since some medicines (vaccinations) require 
	specific, and sometimes extreme, low temperatures. As the medicines are in route from manufacturer 
	to end user, the change in ownership, along with the container temperature, may be stored in a DLT. 
	It will then be vital to provide interoperability between the DLT, or non-DLT, systems along this supply 
	chain in order to provide consistency, transferrability and accountability. If it's determined, by looking 
	at DLT data, that the required temperature was not maintained at a certain point of time then the 
	pharmaceutical asset can be identified, removed and insurance can be claimed.</t>
	</section>
	
	<section title="Farm to store">
	<t>DLT interoperability will provide much needed food traceability along the farm to store supply chain. 
	The change of asset ownership is tracked as the shipping partners send the transportation data to a 
	DLT or general distributed database. The data tracked includes temperature, humidity, time, capacity 
	and any other variables used to help with any insurance claims for spoiled produce. Tracking this	
	data, across DLTs, will also help prevent counterfeit goods from being shipped. </t> 
	</section>
	
	<section title="Energy"> 
	<t>Interoperability between energy producers will help secure energy trading and delivery. The energy 
	industry must be able to function with increasingly complex transactions between big and small producers,
	which now includes home, and corporate, consumers becoming energy producers. Increased volumes
	of decentralized energy are being produced. Home owners, companies and tradition energy utilities will 
	want to have accurate and secure accounting of their energy assets by inputting the data onto a DLT. The 
	new energy partnering will become increasingly complex and it will be imperative for the energy assets to 
	be properly tracked and traded along an interoperable ecosystem.</t>
	</section>

     </section>

   <section title="Use-Case: Interconnection of Cloud Systems">

	<t>There will be an increasing need for cloud interoperability particularly with the need to transfer
	payment from one cloud platform to another. If a blockchain exists in AWS, for instance, and an asset
	needs to be transferred to a blockchain located in an Azure environment, an interoperability gateway will need to exist. This is
	true also for the growing metaverse where decentralized asset transfer solutions using blockchain exist. 
	As various metaverse cloud ecosystems continue to be created there will need to be a way to transfer currency 
	(and other assets) from one ecosystem to another. If you are playing a game in Meta's metaverse and need to 
	pay for an asset to be transferred to another (or same) game in Microsofts metaverse, there will need to be a solution for 
	blockchain interoperability. </t>   

     </section>
		

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>


  </middle>




  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->


	<references title="Normative References">
      <!--?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;


	</references>



	<references title="Informative References">

    
		<reference anchor="MAS19" target="https://www.mas.gov.sg/-/media/MAS/ProjectUbin/Jasper-Ubin-Design-Paper.pdf">
		<front>
			<title>Jasper-Ubin Design Paper, Enabling Cross-Border High Value Transfer Using Distributed Ledger Technologies, Monetary Authority of Singapore.</title>
			<author initials="" surname="MAS">
			</author>
			<date day="" month="May" year="2019"/>
		</front>
		</reference>


		<reference anchor="SKS18" target="https://arxiv.org/pdf/1801.01421.pdf">
		<front>
			<title>Towards Application Portability on Blockchains, Proc. IEEE HotICN 2018</title>
			<author initials="K." surname="Shudo">		</author>
			<author initials="R." surname="Kanda">			</author>
			<author initials="R." surname="Saito">			</author>
			<date day="" month="August" year="2018"/>
		</front>
		</reference>


		<reference anchor="STOA19" target="https://www.europarl.europa.eu/RegData/etudes/STUD/2019/634445/EPRS_STU(2019)634445_EN.pdf">
		<front>
			<title>EU STOA, Blockchain and the GDPR: Can distributed ledgers be squared with European data protection law?, EU European Parliamentary Research Service, STOA, PE 634.445.</title>
			<author initials="" surname="STOA">
			</author>
			<date day="" month="July" year="2019"/>
		</front>
		</reference>


		<reference anchor="Scot19" target="https://www.ibm.com/blogs/think/2018/11/tradelens-how-ibm-and-maersk-are-sharing-blockchain-to-build-a-global-trade-platform/">
		<front>
			<title>TradeLens: How IBM and Maersk Are Sharing Blockchain to Build a Global Trade Platform. IBM Report</title>
			<author initials="T." surname="Scott">		</author>
			<date day="27" month="November" year="2018"/>
		</front>
		</reference>



		
      
	</references>


    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>