Skip to main content

Protocol for Requesting and Sharing Views across Networks
draft-ramakrishna-satp-data-sharing-02

Document Type Active Internet-Draft (individual)
Authors Venkatraman Ramakrishna , Vinayaka Pandit , Ermyas Abebe , Sandeep Nishad , Dhinakaran Vinayagamurthy
Last updated 2024-07-08
Replaces draft-ramakrishna-sat-data-sharing
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
GitHub Organization
GitHub Username: VRamakrishna
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ramakrishna-satp-data-sharing-02
Internet Engineering Task Force                  Venkatraman Ramakrishna
Internet-Draft                                              IBM Research
Intended status: Informational                           Vinayaka Pandit
Expires: January 5, 2025                                    IBM Research
                                                            Ermyas Abebe
                                                               Consensys
                                                          Sandeep Nishad
                                                            IBM Research
                                               Dhinakaran Vinayagamurthy
                                                            IBM Research
                                                            July 5, 2024

        Protocol for Requesting and Sharing Views across Networks
                 draft-ramakrishna-satp-data-sharing-02

Abstract

   With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there is a
   need for asset-related data and metadata to traverse system boundaries
   and link their respective business workflows. Systems and networks can
   define and project views, or asset states, outside of their boundaries,
   as well as guard them using access control policies, and external agents
   or other systems can address those views in a globally unique manner.
   Universal interoperability requires such systems and networks to request
   and supply views via gateway nodes using a request-response protocol. The
   endpoints of this protocol lie within the respective systems or in
   networks of peer nodes, but the cross-system protocol occurs through the
   systems’ respective gateways. The inter-gateway protocol that allows an
   external party to request a view by an address and a DLT system to return
   a view in response must be DLT-neutral and mask the internal
   particularities and complexities of the DLT systems. The view generation
   and verification modules at the endpoints must obey the native consensus
   logic of their respective networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2025.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

1.  Introduction

   Blockchain systems, especially those of the permissioned variety, are a
   heterogeneous mix, fulfilling a diverse range of needs and built on
   several different DLT stacks that are not compatible with each other.
   Yet, in an interconnected world, the business processes running on each
   system cannot afford to remain isolated and the virtual assets they
   manage cannot afford to remain in siloes.  These systems must be
   interoperable so that assets can move, and their properties can be
   reflected across network boundaries, and so that business processes can
   span multiple systems.  Interoperability will, in effect, mimic a larger
   or scaled up, blockchain system composed of smaller blockchain systems
   without explicitly requiring those systems to coalesce.

   At the core of any cross-blockchain system transaction is the ability of
   a system to project a view of assets and associated data recorded on its
   ledger to external parties, be they individual agents or other blockchain
   systems.  On the reverse, a blockchain system must also have the ability
   to identify and address views of assets or associated data in another
   system, and further, to validate that view before its business process
   consumes it.  View projection, addressing, and consumption, must
   eliminate or minimize the role of third parties to avoid loss of data
   privacy, control over business process, or diminishment of autonomy.        

   This document specifies an end-to-end protocol whereby a view request and
   the corresponding view response can be communicated using two or more
   gateway nodes connected to the end DLT systems. The gateways communicate
   with each other using a DLT-neutral protocol (like SATP [SATP], or
   variations of it) and therefore the view requests and responses must be
   encapsulated in DLT-neutral data formats. Beyond the gateways, and into
   the DLT systems, view generation and consumption rely upon native
   mechanisms exposed by those systems. The gateways must therefore be
   augmented to exercise these mechanisms to convey view requests and
   responses to their respective back-end systems.

   The purpose of this document is to provide a technical framework 
   to discuss the various aspects of a basic view request-response
   protocol via gateways acting on behalf of blockchain/DLT systems,
   including security and privacy considerations.

2.  Terminology

   There following are some terminologies used in the current document:

   o  Blockchain system: Blockchains are distributed digital ledgers of
      cryptographically signed transactions that are grouped into
      blocks.  Each block is cryptographically linked to the previous
      one (making it tamper evident) after validation and undergoing a
      consensus decision.  As new blocks are added, older blocks become
      more difficult to modify (creating tamper resistance).  New blocks
      are replicated across copies of the ledger within the network, and
      any conflicts are resolved automatically using established rules
      [NIST].

   o  Blockchain network: This is a blockchain system that is built on a
      network of nodes that maintain a common shared copy of the blockchain
      using a consensus protocol.

   o  Distributed ledger technology (DLT) system: Technology that
      enables the operation and use of distributed ledgers, where the
      ledger is shared (replicated) across a set of DLT nodes and
      synchronized between the DLT nodes using a consensus mechanism
      [ISO].  Every blockchain system is also a DLT system, and so we
      will mostly use the latter term in this draft when discussing
      protocols for cross-system interactions.

   o  Distributed ledger network: This is a DLT system that is built on a
      network of nodes that maintain a shared copy of the ledger or portions
      of it on different subsets of nodes using a consensus protocol.

   o  Resource Domain: The collection of resources and entities
      participating within a blockchain or DLT system.  The domain
      denotes a boundary for permissible or authorized actions on
      resources.

   o  Interior Resources: The various interior protocols, data
      structures and cryptographic constructs that are a core part of a
      blockchain or DLT system.  Examples of interior resources include
      the ledger (blocks of confirmed transaction data), public keys on
      the ledger, consensus protocol, incentive mechanisms, transaction
      propagation networks, etc.

   o  Exterior Resources: The various resources that are outside a
      blockchain or DLT system, and are not part of the operations of
      the system.  Examples include data located at third parties such
      as asset registries, ledgers of other blockchain/DLT systems, PKI
      infrastructures, etc.

   o  Nodes: The nodes of the blockchain or DLT system which form the
      peer-to-peer network, which collectively maintain the shared
      ledger in the system by following a consensus algorithm.

   o  Gateway nodes: The nodes of the blockchain or DLT system that are
      functionally capable of acting as a gateway in an asset transfer.
      A gateway node conforms to the Secure Asset Transfer Architecture
      [SATA] and implements the Secure Asset Transfer Protocol (SATP)
      [SATP].  Being a node on the blockchain/DLT system, a gateway has at
      least read access to the interior resources (e.g., ledger) of the
      blockchain.  Optionally, it may have write access to the ledger and
      also the ability to participate in the consensus mechanism deployed
      for the system.  Depending on the blockchain/DLT system
      implementation, some or all of the nodes may be gateway-capable.

   o  Gateway device identity: The identity of the device implementing
      the gateway functions.  The term is used in the sense of IDevID
      (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID].

   o  Gateway owner: The VASP who legally owns and operates a gateway
      node within a blockchain system.

   o  Clients: Entities are permitted to invoke smart contracts to read
      or update ledger state in a blockchain or DLT system. They possess
      unique identities in the form of public keys.  In a permissioned 
      system, identity certificates are issued by the system's internal
      providers (or certificate authorities).

   o  Wallets: Collection of client identities represented by public-
      private  key pairs, and optionally certificate issued by a
      blockchain or DLT system's identity providers (or certificate
      authorities).

   o  Virtual Asset: A virtual asset is a digital representation of
      value that can be digitally traded, or transferred as defined by
      the FATF [FATF].

   o  Virtual Asset Service Provider (VASP): Legal entity handling
      virtual assets as defined by the FATF [FATF].

   o  Ledger state: A snapshot of the information held in a distributed
      shared ledger, typically (though not necessarily) as a set of
      blockchain or DLT system.  Examples of interior resources include
      key-and-value pairs. This information includes records of virtual
      assets and the state of business processes that are meaningful to
      the DLT system's participants and clients.  State elements and
      subsets may be scoped under the namespaces of given smart contracts,
      thereby being accessible only through invocations on those contracts.

   o  Smart contracts: Business workflows written in programming languages
      that manage the states of assets and business processes on a shared
      ledger in a DLT system.  These contracts constrain the ability of
      system clients to modify ledger state and embed guards around state
      elements.  Contracts can be invoked to read from, or write, to, a
      ledger.  They can be deployed on several system nodes, who must
      agree on a given ledger state update via a consensus protocol.

   o  Consensus protocol/mechanism: Process by which nodes agree on a 
      ledger state update, typically (though not mandatorily) through a
      smart contract invocation.

   o  Local transaction: A transaction triggered by a client to update
      the ledger state in a blockchain or DLT system, typically (though not
      mandatorily) through a smart contract invocation.

   o  View: A projection of a blockchain or DLT system's ledger state
      for external consumption, i.e., for parties outside that system.
      This can be a single element, a subset of the state, or a function
      over a subset.

   o  View Address: A unique identifier or locator for a view into a
      blockchain or DLT system's ledger.  This is analogous to an HTTP URL.

   o  Source system: Blockchain or DLT system governing the ledger from
      which a view is produced.

   o  Destination system: System in which a view is consumed.  This can
      be a blockchain or DLT system.

   o  Remote system: Counterparty system in a view request-response
      protocol instance.  From the vantage point of the source system,
      this refers to the destination system, and vice versa.

   o  View requestor: Person or organization triggering a view request
      from a source network.

   o  Proof: A data structure containing evidence linking a view to its
      source system's blockchain, or more generally, ledger.  The evidence
      may be probabilistic and in some cases cryptographically verifiable.

   o  Access/exposure policy: Set of rules governing the release of a view
      to an external party (i.e., outside the source system), held in
      consensus by nodes on the source system's ledger.

   o  Verification policy: Rules for validation of proofs associated with 
      views maintained in a destination system. If the destination system
      is a blockchain or DLT system, these rules are held in consensus by
      nodes on the that system's ledger.

   o  View Request: A request for a made by an external party to a source
      blockchain or DLT system.  The external party may be a client in
      a destination blockchain or DLT system.  The request consists of a
      view address and various metadata, including optionally a
      verification policy.

   o  Asset locking or escrow: The conditional mechanism used within a
      blockchain or DLT system to make an asset temporarily unavailable
      for use by its owner.  The condition of the asset release can be
      based on a duration of time (e.g., hash time locks) or other
      parameters.

   o  Gateway crash recovery: The local process by which a crashed
      gateway (i.e., device or system fault) is returned to a consistent and
      operational state, ready to resume the asset transfer protocol with
      the peer gateway prior to the crash event.

   Further terminology definitions can be found in [NIST] and [ISO].
   The term 'blockchain' and 'distributed ledger technology' (DLT) are
   used interchangeably in this document.

3.  Assumptions and Principles

   The following assumptions and principles underlie the design of the
   current interoperability architecture and protocol enabling the
   requesting and sharing of data from across DLT systems using gateways,
   and correspond to the design principles of the Internet architecture.

3.1.  Design Principles

   The protocol must not involve any centralized intermediaries or trusted
   third parties, including settlement blockchains, other than gateways. The
   protocol must not decrease the security of endpoint blockchain systems
   nor impose a higher bar on their internal consensus. Further, the
   protocol must not reveal any private information from a system beyond
   what the nodes of that network have agreed to through consensus. The
   protocol must enable view requests and response from systems built on any
   arbitrary (present or future) blockchain or distributed ledger
   technology.  Finally, the endpoint systems must retain full autonomy over
   internal governance and framing of policies governing how views can be
   exposed and how proofs can be validated.

3.2.  Operational Assumptions

   The following conditions are assumed to have occurred prior to the
   construction of a view request:

   o  Syncing remote system structure, memberships, and identities: see 
      Section 10 for details.

   o  Recording view access control policies in the source ledger: see 
      Section 10 for details.

   o  Recording view verification policies in the destination ledger: see 
      Section 10 for details.

4.  Interoperability and Data Sharing Among Distributed Ledger Systems

   Distributed ledger systems, typically maintained through consensus on a
   network of peer nodes, run business workflows (often as “smart contracts”
   [Ethe22]) and maintain transaction logs. The ledgers and their
   transaction histories are distinct, but the business workflows they run
   are often interlinked in the real world. This necessitates
   interoperability among the systems/networks as well as the ledgers
   maintained by them. Certain modes, or patterns, of interoperability have
   been identified as typical and useful for the enterprises and consortia
   that run these systems. These are listed in the Secure Asset Transfer
   architecture draft [SATA], namely as asset transfer, asset exchange, and
   data sharing, respective. Motivating use cases for these different modes
   have been presented in the Secure Asset Transfer use cases draft [SATU].

   In this document, we will address the data sharing mode of
   interoperability, whereby DLT systems can export views of their ledger
   state with associated proofs of authenticity, control access to these
   views, and also address views exported by a remote DLT system. The
   formats of the views, addresses, requests, and access control policies
   are beyond the scope of this draft, and are specified in the Views and
   View Addresses draft [SATV]. This draft specified a request-response
   protocol whereby a view can be requested from one DLT system to another
   via those systems’ respective gateways, and obtained and consumed via the
   same gateways. In effect, data maintained on the ledger in one system is
   shared with another in a way that requires no third-party system or agent
   acting as a mediator.

   This draft will only specify a bilateral protocol, i.e., whereby a view
   is requested by a DLT system to exactly one other DLT system and whereby
   a view is supplied by a DLT system with exactly one other DLT system.
   Extrapolating or augmenting this protocol to involve more than two DLT
   systems is beyond the scope of the present draft.

5.  Data Sharing Protocol

   This section describes a protocol using which an external entity can
   request and process a view from a distributed ledger.

5.1.  Goal and Overview of Protocol

   Using this protocol, any entity, be it a single application or agent or a
   distributed ledger system itself, can supply a view address and a
   verification policy to a distributed ledger system and obtain a view in
   response, which it can then validate before processing as per need. This
   protocol makes no assumption about the nature of such processing, which
   can be executed by some module (like a smart contract) but rather
   prescribes the steps to be followed until the point where the view is
   dispatched to the module.

   The diagram below illustrates the protocol whereby a distributed ledger
   system requests and consumes a view from another distributed ledger
   system. The protocol units are indicated, with sequence numbers
   associated with procedures or messages.

    +----------------------------+
    |           Client           |
    |       (Application)        |
    +----------------------------+
          |               ^     |
          |       7 View  |     |
   8 View |      Response |     | 1 View
          |               |     | Request
          V               |     V
   +----------------+   +---------+         +---------+   +----------------+
   |                |   |         | 2 View  |         |   |                |
   |     DLT L1     |   |         | Request |         |   |     DLT L2     |
   |                |   |         |-------->|         | 3 |                |
   | +------------+ |   | Gateway |         | Gateway |-->| +------------+ |
   | |  9  View   | |---|    G1   |         |    G2   |   | |  4 Access  | |
   | | Validation | |   |         |         |         |<--| |  Control & | |
   | |      &     | |   |         |<--------|         | 5 | |    View    | |
   | | Commitment | |   |         | 6 View  |         |   | | Generation | |
   | +------------+ |   |         | Response|         |   | +------------+ |
   +----------------+   +---------+         +---------+   +----------------+

   In a shorter form of the protocol, the requesting system is a unitary
   entity rather than a network of peers maintaining a distributed ledger
   and a client application above it. The diagram below illustrates this
   protocol and its units, with sequence numbers associated with procedures
   or messages.

   +-----------------------+            +---------+   +----------------+
   |                       |   1 View   |         |   |                |
   |         Client        |   Request  |         |   |      DLT L     |
   |     (Application)     |----------->|         | 2 |                |
   |                       |            | Gateway |-->| +------------+ |
   | +-------------------+ |            |    G    |   | |  3 Access  | |
   | | 6 View Validation | |            |         |<--| |  Control & | |
   | |    & Commitment   | |<-----------|         | 4 | |    View    | |
   | +-------------------+ |   5 View   |         |   | | Generation | |
   |                       |  Response  |         |   | +------------+ |
   +-----------------------+            +---------+   +----------------+

   The distributed ledger system on the right is referred to as the source
   system, as it is the source of the information being requested for
   through a view. The system on the left is referred to as the destination
   system, as the desired information ends up there either in raw or in
   processed form. The destination system can be a traditional centrally
   governed system or a distributed ledger system maintained by a
   decentralized network.

5.2.  Protocol Phases

   The protocol can be divided into the following phases:
   o  Phase 1: View request creation in destination network.
   o  Phase 2: Cross-gateway discovery and request.
   o  Phase 3: View creation in source network.
   o  Phase 4: Cross-gateway response.
   o  Phase 5: View validation and commitment in destination system.

5.3.  Phase 1: View request creation in destination network

   All operations in this phase are conducted by a client, typically acting
   through an application, in the destination system.
   o  The client constructs a view address corresponding to the desired
      view.
   o  The client looks up the verification policy corresponding to this view
      address from the destination system’s database. If the destination
      system is a distributed ledger system, this lookup should involve a
      query to one or more shared ledgers within the system.
   o  The client sends a view request comprising of the view address and the
      verification policy to the destination system’s gateway.

5.4.  Phase 2: Cross-gateway discovery and request

   All operations in this phase are conducted by a gateway belonging to, or
   acting on behalf of, the destination system.
   o  The destination system’s gateway looks up or tried to discover the
      address of one or more gateways belong to, or working on behalf of,
      the source system. If no address can be found, the protocol
      terminates.
   o  The destination system’s gateway selects an address and sends the view
      request to the source system’s gateway at that address.

5.5.  Phase 3: View creation in source network

   Operations in this phase are orchestrated by a source system gateway via
   the system’s smart contract transaction and network consensus mechanisms.
   o  The source system’s gateway converts the view request into a
      distributed ledger query or a smart contract invocation (if the source
      system supports smart contracts). The following steps show how this
      happens in a permissioned distributed ledger system with smart
      contracts.
      o  The source system’s gateway parses the view address within the view
         request to formulate a view data query and determine the ledger
         from which a view is desired.
      o  The source system’s gateway parses the verification policy in the
         view request to determine a subset of peers within its network that
         maintain this ledger and to which this query can be sent.
      o  The source system’s gateway invokes a smart contract to process the
         view data query, in effect by sending the query to the selected
         network peers.
      o  Each peer that receives the query:
         o  Validates the query against the source system’s access control
            policy.
         o  Processes the query and produces an output if the validation is
            successful.
         o  Packages and signs the output, which can be a query response or
            a failure report, as it would do with any regular smart contract
            transaction result. The signature constitutes part of the proof
            for satisfaction of the verification policy.
         o  Sends the signed package to the source system’s gateway.
   o  The source system’s gateway creates a view from the smart contract
      invocation result. If this invocation follows the process described in
      the preceding steps, this is done by collecting and enveloping the
      received packages into a view structure.

5.6.  Phase 4: Cross-system response

   o  The source system’s gateway sends the view to the destination system’s
      gateway. It may do this as a response in a long-running session that
      began with the latter sending a view request to the former.
      Alternatively, this could be done by the former posting an event to
      the latter. Sending of the view could be a best effort process or
      guaranteed through suitable fault tolerance mechanisms built into
      gateways. Such mechanisms are beyond the scope of this draft.
   o  The destination system’s gateway sends the view to the client that
      created the original view request. The same mechanisms and
      considerations apply as in the cross-gateway response in the preceding
      step.

5.7.  Phase 5: View validation and commitment in destination system

   All operations in this phase are conducted by the client in the
   destination system that created the original view request.
   o  The client parses the view to determine if the request was successful.
      If not, the protocol terminates.
   o  If the destination system is a centrally governed system with a
      database, the client submits a transaction, using an available API,
      with the view in the arguments. If the destination system is a
      distributed ledger system, the client submits a smart contract
      transaction, with the view in the arguments, to the destination
      system’s network peers.
   o  The backend system (if the destination system is centrally governed)
      or every peer in the network (if the destination system is a
      distributed ledger system) that receives the transaction validates the
      proof within the view against the verification policy recorded in the
      database or the shared ledger.
   o  If the proof is determined to be invalid, the protocol terminates.
      Otherwise, the transaction is executed and then committed to storage,
      either through a unitary procedure (centrally governed system) or
      through distributed consensus (distributed ledger system).

5.8.  Desirable Properties of Data Sharing Protocols

   The desirable properties of a data sharing protocol include, but are not
   limited to, the following: 
   o  Decoupling gateways from systems: the protocol should not rely on a
      specific implementation of a gateway or a cross-gateway communication
      protocol, nor should the protocol be restricted to a particular pair
      of view generation-validation processes in the respective systems.
      Different components and even systems can be replaced without
      requiring modifications to the high-level protocol semantics.
   o  Technology-neutral cross-gateway communication: the cross-gateway
      communication protocol, e.g., SATP [SATP], should be oblivious to the
      nature and implementation of the endpoint systems. As a corollary, the
      protocol units internal to the system should also be oblivious to the
      cross-gateway discovery and communication mechanisms.
   o  Trust through native consensus: end-to-end trust should be realized by
      implementing the view generation and validation procedures the same
      way as any distributed consensus-driven operation in the respective
      systems. This respects the native decision-making processes in those
      systems and enables multi-party groups backing those systems to
      interact with each other as units.
   o  Minimize trust in gateways: the integrity of the protocol should not
      be dependent on the reliability of either gateway. The next sub
      section elaborates on the desired security properties.
   o  Preserving system autonomy and self-sovereignty: the endpoint systems
      should have complete freedom in determining their respective access
      controls and verification policies, and in choosing when to initiate a
      view request or whether to respond to a view request. The internal
      activities of each system should be oblivious to the other and should
      not affect data sharing protocol instance.
   o  Accommodating heterogeneity: the end-to-end protocol should work the
      same regardless of the distributed ledger technology implementation
      backing either endpoint system.
   o  Avoid synchronization: the protocol should not rely on any externally
      guided synchronization mechanism, such as a global clock, and instead
      rely purely on asynchronous message transfers.

5.9.  Security Considerations

   The security considerations of the protocol include, but are not limited
   to, the following:
   o  Distributed consensus: rely on the consensus mechanism of the
      counterparty system both to authenticate view requests and to validate
      views. This can mitigate (or avoid) Byzantine failure of malicious
      nodes within the endpoint systems. It can also prevent a malicious
      client from supplying a fake view in the destination system.
   o  Integrity: rely on digital signatures over the view requests and
      responses (made by the client in the destination system and peers in
      the source system) so that the gateways cannot tamper with the
      messages undetected.
   o  Confidentiality: rely on end-to-end encryption of the view response so
      that the gateways cannot exfiltrate the view contents and/or the
      associated proofs. Exfiltration will violate the access control
      policies of the source system.
   o  Availability: rely on redundancy and failover to mitigate against
      denial-of-service attacks mounted by either gateway. Multiple gateways
      should be configured and kept on standby in practice.

5.10.  Privacy Considerations

   Access control policies allow source systems to have privacy by default,
   and only reveal the minimum ledger information necessary to external
   entities. Any data shared across two systems is private between them
   only if the gateways are maintained by stakeholders within the respective
   systems. This should be kept in mind when selecting or discovering
   gateways for data sharing instances.

5.11.  Fault Tolerance and Crash Recovery

   The usual considerations of fault tolerance, crashes, and session
   maintenance, apply to gateways involved in data sharing. Various
   techniques for failover and session state and log backups can be used to
   guard against, or recover from, the possibility of either gateway failing
   during a data sharing instance. Details are beyond the scope of this
   draft, which makes no recommendations on this topic either.

6.  Pre-request setup and configuration

   Either endpoint system in a data sharing protocol instance must have the
   following configured in their respective data stores, which, if the
   system is a distributed ledger system, should be a shared ledger.
   o  View request access control policies: as described in Section 8, one
      or more access control policy rules according to the given
      specification should be recorded before a data sharing protocol
      instance. If a view request is received by a system and there is no
      appropriate policy rule in the system’s record, the principle of least
      privilege should be applied, and the view request rejected.
   o  View verification policies: as described in Section 6, one or more
      verification policies according to the given specification should be
      recorded before a data sharing protocol instance. If a view is
      received by a system and there is no appropriate policy rule in the
      system’s record, the view should be deemed invalid. The client itself
      ought to avoid sending a view request if an appropriate verification
      policy cannot be retrieved, but even if a malicious client proceeds
      with a spurious view request, the destination system’s back end should
      declare the proof accompanying the view response to be invalid.
   o  External identities and certifications: participating systems can be
      abstracted into one or more security domains that represent the
      stakeholders of that system. For effective policy enforcement, i.e.,
      to authenticate a view request or validate a view, knowledge of a
      remote system’s security domains—identity providers, certification
      authorities, and group structure if the system is a distributed
      ledger—is necessary. This information is typically, though not limited
      to, a set of certificate hierarchies, which should be determined and
      recorded to the system’s data store before a data sharing protocol
      instance. In the absence of such recorded information about the
      counterparty system, the protocol should terminate in the view request
      access control check step or in the view validation step.

7.  Related Open Issues

   This draft provides a specification for views and how to addresses them.
   It further describes a protocol whereby one system can request a view
   from another through gateways. But there are several aspects of the end
   to-end process, which are extraneous to the data sharing protocol yet
   crucial to its successful completion. Though detailed specifications of
   these are beyond the scope of this draft, we list them in this section
   for readers’ considerations.

7.1.  Global identification of blockchain systems and public keys

   To construct a view address as well as determine a suitable gateway to
   send a view request to, we need identifiers and naming systems for
   distributed ledgers and the networks that maintain them. In addition, we
   need ways to associate public keys with these names for authentication
   purposes. Further, we need mechanisms to store and retrieve these
   identifiers and keys in a distributed, and ideally decentralized, manner.
   The concepts of Decentralized Identifiers [DID] and Self-Sovereign
   Identity [SSI] are promising technologies to begin devising such
   specifications.

7.2.  Discovery of gateways nodes within a blockchain system

   To initiate a data sharing protocol, a client in a distributed ledger
   system needs to identify a suitable gateway node. This can be done in
   several different ways, one of which involves registering the set of
   gateways on a shared ledger within the system. Because, ideally, the
   gateway does not need to be highly trusted, there are few security
   implications but potentially larger efficiency implications in the choice
   of mechanism for registration and discovery of local gateway nodes.

7.3.  Remote gateway discovery

   How gateways can discover other gateways acting on behalf of remote
   distributed ledger systems is an open question. The problem can be
   related to the routing problem (i.e., discovery of routing paths) in
   packet networking [RFC791].

7.4.  Decentralized identity management across distributed ledger systems

   Mechanisms are required to continuously sync external identities and
   certifications as described in Section 10 as a basis for data sharing.
   To keep these mechanisms are decentralized as possible and leverage
   existing identity registries, we can leverage the concepts of
   decentralized identifiers [DID] and verifiable credentials [VC22].
   Protocols for this purpose, which use DID registries and trust anchors,
   have been proposed [WRFCDID], and we can use them as
   starting points for this specification.

8.  References

8.1.  Normative References

   [DID]      Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O.,
              and C. Allen, "Decentralized Identifiers (DIDs) v1.0, W3C
              Recommendation", July 2022, <https://w3c.github.io/did-core/>.

   [FATF]     FATF, "International Standards on Combating Money
              Laundering and the Financing of Terrorism and
              Proliferation - FATF Revision of Recommendation 15",
              October 2018, <http://www.fatf-
              gafi.org/publications/fatfrecommendations/documents/fatf-
              recommendations.html>.

   [ISO]      ISO, "Blockchain and distributed ledger technologies-
              Vocabulary (ISO:22739:2020)", July 2020,
              <https://www.iso.org>.

   [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
              Blockchain Technology Overview (NISTR-8202)", October
              2018, <https://doi.org/10.6028/NIST.IR.8202>.

   [RFC791]   Information Sciences Institute, University of Southern
              California, "Internet Protocol, DARPA Internet Program,
              Protocol Specification, IETF RFC 791", September 1981,
              <https://datatracker.ietf.org/doc/html/rfc791>.

   [SATA]     Hardjono, T., Hargreaves, M., Smith, N., and V. Ramakrishna,
              "Secure Asset Transfer (SAT) Interoperability Architecture,
              IETF, draft-ietf-satp-architecture-05.", June 2024,
              <https://datatracker.ietf.org/doc/draft-ietf-satp-
              architecture/>.

   [SATP]     Hargreaves, M., Hardjono, T., and R. Belchior,
              "Secure Asset Transfer Protocol (SATP) Core, IETF,
              draft-ietf-satp-core-04.", April 2024,
              <https://datatracker.ietf.org/doc/draft-ietf-satp-core/>.

   [SATU]     Ramakrishna, V., and T. Hardjono, "Secure Asset Transfer (SAT)
              Use Cases, IETF, draft-ietf-satp-usecases-03.", July 2024,
              <https://datatracker.ietf.org/doc/draft-ietf-satp-usecases/>.

   [SATV]     Ramakrishna, V., Pandit, V., Abebe, E., Nishad, S., and K.
              Narayanam, "Views and View Addresses for Secure Asset
              Transfer, IETF, draft-ramakrishna-satp-views-addresses-03.",
              July 2024, <https://datatracker.ietf.org/doc/draft-
              ramakrishna-satp-views-addresses/>.

   [SSI]      Tobin, A., and D. Reed, "The Inevitable Rise of Self-Sovereign
              Identity, A white paper from the Sovrin Foundation",
              March 2017, <https://sovrin.org/wp-content/uploads/2018/03/
              The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf>.

   [VC22]     Sporny, M., Longley, D., and D. Chadwick, "Verifiable
              Credentials Data Model v2.0, W3C Editor’s Draft", August 2022,
              <https://w3c.github.io/vc-data-model/>.

8.2.  Informative References

   [ABCH20]   Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
              T. Hardjono, "Proposal for a Comprehensive Crypto Asset
              Taxonomy", May 2020, <https://arxiv.org/abs/2007.11877>.

   [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
              Correia, "A Survey on Blockchain Interoperability: Past,
              Present, and Future Trends", May 2020,
              <https://arxiv.org/abs/2005.14282v2>.

   [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet
              Protocols, ACM Computer Communication Review, Proc SIGCOMM
              88, vol. 18, no. 4, pp. 106-114", August 1988.

   [Ethe22]   "Ethereum Whitepaper", September 2022,
              <https://ethereum.org/en/whitepaper/>.

   [Gray81]   Gray, J., "The Transaction Concept: Virtues and
              Limitations, in VLDB Proceedings of the 7th International
              Conference, Cannes, France, September 1981, pp. 144-154",
              September 1981.

   [Herl19]   Herlihy, M., "Blockchains From a Distributed Computing
              Perspective, Communications of the ACM, vol. 62, no. 2,
              pp. 78-85", February 2019,
              <https://doi.org/10.1145/3209623>.

   [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards and
              Interoperability Architecture for Blockchain Autonomous
              Systems, IEEE Transactions on Engineering Management",
              June 2019, <https://doi:10.1109/TEM.2019.2920154>.

   [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted
              Computing Base for Blockchain Infrastructure Security,
              Frontiers Journal, Special Issue on Blockchain Technology,
              Vol. 2, No. 24", December 2019,
              <https://doi.org/10.3389/fbloc.2019.00024>.

   [IDevID]   Richardson, M. and J. Yang, "A Taxonomy of operational
              security of manufacturer installed keys and anchors. IETF
              draft-richardson-t2trg-idevid-considerations-01", August
              2020, <https://tools.ietf.org/html/draft-richardson-t2trg-
              idevid-considerations-01>.

   [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
              in System Design, ACM Transactions on Computer Systems,
              vol. 2, no. 4, pp. 277-288", November 1984.

   [WRFCDID]  Ramakrishna, V., Narayanam, K., Chandra Ghosh, B., 
              and E. Abebe, "Decentralized Network-Identity Discovery and
              Management for Interoperation, Hyperledger Labs, Weaver: DLT
              Interoperability, RFC 01-011", August 2022,
              <https://github.com/hyperledger-labs/weaver-dlt-
              interoperability/blob/main/rfcs/models/identity/network-
              identity-management.md>.

Contributors

   The authors would like to thank Krishnasuri Narayanam of IBM Research,
   India, for discussing and brainstorming the ideas and specifications
   presented in this draft, and subsequently reviewing this draft and
   providing constructive suggestions for its improvement.
   draft and providing constructive suggestions for its improvement.

 
Authors' Addresses

   Venkatraman Ramakrishna
   IBM Research,
   Bangalore, India

   Email: vramakr2@in.ibm.com

   Vinayaka Pandit
   IBM Research
   Bangalore, India

   Email: pvinayak@in.ibm.com

   Ermyas Abebe
   Consensys
   Melbourne, Australia

   Email: ermyas.abebe@consensys.net

   Sandeep Nishad
   IBM Research
   Bangalore, India

   Email: sandeep.nishad1@ibm.com

   Dhinakaran Vinayagamurthy
   IBM Research
   Bangalore, India

   Email: dvinaya1@in.ibm.com