Open Digital Asset Protocol
draft-hargreaves-odap-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Martin Hargreaves , Thomas Hardjono | ||
| Last updated | 2020-10-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-hargreaves-odap-00
Internet Engineering Task Force M. Hargreaves
Internet-Draft Quant Network
Intended status: Informational T. Hardjono
Expires: April 13, 2021 MIT
October 10, 2020
Open Digital Asset Protocol
draft-hargreaves-odap-00
Abstract
This memo describes the Open Digital Asset Protocol (ODAP). ODAP is
intended for describing assets held on distributed ledgers in an open
and interoperable format, session negotiation and message passing
between gateways connecting disparate blockchain systems.
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 April 13, 2021.
Copyright Notice
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hargreaves & Hardjono Expires April 13, 2021 [Page 1]
Internet-Draft ODAP October 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Open Digital Asset Protocol . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. ODAP: Elements of the proposal . . . . . . . . . . . . . . . 4
3.1. ODAP Message Flow Context . . . . . . . . . . . . . . . . 4
3.2. ODAP Message Format . . . . . . . . . . . . . . . . . . . 4
3.3. Digital Asset Resource Descriptors . . . . . . . . . . . 5
3.3.1. Organisation Identifier . . . . . . . . . . . . . . . 5
3.3.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 5
3.3.3. DLT Identifier . . . . . . . . . . . . . . . . . . . 5
3.3.4. Resource . . . . . . . . . . . . . . . . . . . . . . 6
3.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Digital Asset Resource Client Descriptors . . . . . . . . 6
3.4.1. Organization Identifier . . . . . . . . . . . . . . . 6
3.4.2. DLT Gateway / Endpoint ID . . . . . . . . . . . . . . 6
3.4.3. Organizational Unit . . . . . . . . . . . . . . . . . 7
3.4.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Gateway Level Access Control . . . . . . . . . . . . . . 7
3.6. Negotiation of Security Protocols and Parameters . . . . 8
3.6.1. TLS Established . . . . . . . . . . . . . . . . . . . 8
3.6.2. Client offers supported credential schemes . . . . . 8
3.6.3. Server selects supported credential scheme . . . . . 8
3.6.4. Client asserts of proves identity . . . . . . . . . . 8
3.6.5. Sequence numbers initialized . . . . . . . . . . . . 8
3.6.6. Messages can now be exchanged . . . . . . . . . . . . 9
3.7. Digital Asset Resource Discovery . . . . . . . . . . . . 9
3.7.1. Format . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Accessing Resources via a DLT Gateway . . . . . . . . . . 9
3.8.1. Backward Compatibility . . . . . . . . . . . . . . . 9
4. Security Consideration . . . . . . . . . . . . . . . . . . . 9
5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
There is a lack of interoperability between individual blockchains,
but also a general difficulty building open DLT networks. Extant
networks are custom built and relatively closed, usually limited to
networks of a single DLT type
Hargreaves & Hardjono Expires April 13, 2021 [Page 2]
Internet-Draft ODAP October 2020
This memo proposes at blockchain-agnostic protocol in order to allow
the creation of business applications that use and modify multiple
blockchains or DLT systems, through a single programmatic interface.
The target blockchain systems can be of any type, operated by
different owners and managed using different DLT management platforms
that implement ODAP interfaces.
These platforms may act as gateways or relays for the application to
interact with the blockchain systemn. They are referred to herein as
blockchain or DLT Gateways.
When correctly implemented and deployed, the protocol should provide
the basis for solutions involving asset migration between two DLT
systems, as well as use-cases when one side is a non-DLT system (e.g.
legacy system).
1.1. Open Digital Asset Protocol
This draft proposes a standard framework to address the following:
o Resource addressing for DLTs, using the URL syntax.
o Client identification based on the URN format. These are for
identifying clients (developers and applications) who access these
resources, and which in some use-cases require access
authorization.
o Protocol message family for negotiating authentication,
authorisation, and parameters for confidential channel
establishment.
o Resource discovery mechanism for developers and applications to
discover DLT-based resources hosted at a DLT gateway. The gateway
response is subject to the level of access granted to that
developer or application.
We propose a protocol for accessing DLT resources (read and modify)
that are hosted behind gateways, either directly or via a local
intermediate gateway.
We propose a method to support pass-through of native DLT messaging
where necessary for compatibility.
Hargreaves & Hardjono Expires April 13, 2021 [Page 3]
Internet-Draft ODAP October 2020
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
3. ODAP: Elements of the proposal
This section describes (i) the phases of the ODAP protocol; (ii) the
format of ODAP messages; (iii) the format for resource descriptors;
(iv) a method for gateways to implement access controls; (v) protocol
for negotiating security capabilities; (vi) discovery and accessing
resources and provisions for backward compatibility with existing
systems.
3.1. ODAP Message Flow Context
o OSimple Client to Gateway (Diagram to follow).
o Client to Multiple Gateways (Diagram to follow).
o Client to Local Gateway to Remote Gateway(s) (Diagram to follow).
3.2. ODAP Message Format
ODAP messages are exchanged between applications (clients) and DLT
gateways (servers). They consist of protocol negotiation and
functional messages.
Messages are JSON format, with protocol specific mandatory fields,
support for arbitrary authentication and authorization schemes and
support for a free format field for plaintext or encrypted payloads
directed at the DLT gateway or an underlying DLT.
JSON format message, mandatory fields are shown below:
o Version: ODAP protocol Version (major, minor).
o Resource URL: Location of Resource to be accessed.
o Developer URN: Assertion of developer / application identity.
o Credential Scheme: Specify type of authorization (e.g. SAML,
OAuth, X.509).
Hargreaves & Hardjono Expires April 13, 2021 [Page 4]
Internet-Draft ODAP October 2020
o Credential Block: Credential token, certificate, string.
o Payload: Payload for POST, responses, and native DLT txns.
o Sequence Number: Sequence Number.
3.3. Digital Asset Resource Descriptors
Resources are identified by URL [RFC 1738] as described below:
o The type is new: application/odapres
o The access protocol is ODAP.
Data included in the URL includes the folowing:
3.3.1. Organisation Identifier
This drafts supports a variety organization identification schemes.
For example, the Legal Entity Identifier (LEI)scheme or other
identifier linking resource ownership to real world entity can be
used.
Any scheme for identifying DLT Gateway owners may be implemented
(e.g. LEI directory, closed user group membership, SWIFT BIC, etc.).
The developer or application MAY validate the identity with the
issuing authority. The identifier is not a trusted identity, but MAY
be relied on where trust has been established between the two parties
(e.g. in a closed user group).
The mechanisms to determine organizations identifiers is out of scope
for the current specification.
3.3.2. DLT Gateway / Endpoint ID
FQDN of the ODAP compliant DLT gateway. Required to establish IP
connectivity. This MUST resolve to a valid IP address.
3.3.3. DLT Identifier
Specify to gateway behind which the target DLTs operates. This field
is local to the DLT gateway and is used to direct ODAP interactions
to the correct underlying DLT.
For example: "Hyperledger1", "Bitcoin, "EU-supply-chain".
Hargreaves & Hardjono Expires April 13, 2021 [Page 5]
Internet-Draft ODAP October 2020
3.3.4. Resource
Specifies a resource held on the underlying DLT. This field must be
meaningful to the DLT in question but is otherwise an arbitrary
string. The underlying object it points to may be a DLT address,
block, transaction ID, alias, etc. or a future object type not yet
defined.
3.3.5. Examples
odapres://quant/api.gateway1.com/ripple
odapres://quant/api.gateway1.com/bitcoin/xxxxxADDRESSxxxxx
3.4. Digital Asset Resource Client Descriptors
Resources are identified by URN as described below:
o The type is new: application/odapclient
The URN format does not imply availability or access protocol.
Data included in the URN includes the folowing:
3.4.1. Organization Identifier
Legal Entity Identifier (LEI) or other identifier linking resource
ownership to real world entity. Any scheme for identifying DLT
Gateway owners may be implemented (e.g. LEI directory, closed user
group membership, BIC, etc.).
The DLT Gateway MAY validate the identity with the issuing authority.
The identifier is not a trusted identity, but MAY be relied on where
trust has been established between the two parties (e.g. in a closed
user group).
3.4.2. DLT Gateway / Endpoint ID
Multi-DLT applications can operate in a mode whereby the application
connects to its local DLT gateway, which then forwards application
traffic to local DLTS and to remote DLTs via other ODAP gateways.
Where this is the case, this field identifies the "home" gateway for
this application. This may be required to carry out Gateway to
Gateway handshaking and protocol negotiation, or for the server to
look up use case specific data relating to the client.
Hargreaves & Hardjono Expires April 13, 2021 [Page 6]
Internet-Draft ODAP October 2020
3.4.3. Organizational Unit
The organization unit within the organization that the client
(application or developer) belongs to. This assertion should be
backed up with authentication via the negotiated protocol.
The purpose of this field is to allow DLT gateways to maintain access
control mapping between applications and resources that are
independent of the authentication and authorization schemes used,
supporting future changes and supporting counterparties that operate
different schemes.
3.4.4. Name
A locally unique (within the OU) identifier, which can identify the
application, project or individual developer responsible for this
client connection. This is the most granular unit of access control,
and DLT Gateways should ensure appropriate identifiers are used for
the needs of the application or use case.
3.4.5. Examples
odapclient:quant/api.overledger.quant.com/research/luke.riley
3.5. Gateway Level Access Control
Gateways can enforce access rules based on standard naming
conventions using novel or existing mechanisms such as AuthZ
protocols using the resource identifiers above, for example:
odapclient://hsbc/api.overledger.hsbc.com/lending/eric.devloper
can READ/WRITE
odapres://quant/api.gateway1.com/bitcoin
AND
odapres://quant/api.gateway1.com/ripple
These rules would allow a client so identified to access resources
directly, for example:
odapres://quant/api.gateway1.com/bitcoin/xxxxxADDRESSxxxxx
This example could be an client subscribing to or writing to an
address associated with a smart contract as part of its
functionality.
Hargreaves & Hardjono Expires April 13, 2021 [Page 7]
Internet-Draft ODAP October 2020
This method allows resource owners to easily grant access to
individuals, groups and organizations. Individual gateway
implementations may implement access controls, including subsetting
and supersetting or applications or resources according to their own
requirements.
3.6. Negotiation of Security Protocols and Parameters
3.6.1. TLS Established
TLS 1.2 or higher MUST be implemented to protect gateway
communications. TLS 1.3 or higher SHOULD be implemented where both
gateways support TLS 1.3 or higher.
3.6.2. Client offers supported credential schemes
Capability negotiation prior to data exchange, follows a scheme
similar to the Session Description Protocol [RFC 5939]. Initially
the client (application) sends a JSON block containing acceptable
credential schemes, e.g. OAuth2.0, SAML in the "Credential Scheme"
field of the ODAP message.
3.6.3. Server selects supported credential scheme
The server (DLT Gateway) selects one acceptable credential scheme
from the offered schemes, returning the selection in the "Credential
Scheme" field of the ODAP message.
If no acceptable credential scheme was offered, an HTPP 511 "Network
Authentication Required" error is returned in the Action/Response
field of the ODAP message.
3.6.4. Client asserts of proves identity
The details of the assertion / verification step are specific to the
chosen credential scheme and are out of scope of this document.
3.6.5. Sequence numbers initialized
Sequence numbers are used to allow the server to correctly order
operations from the client, some of which may be asynchronous,
synchronous, idempotent with duplicate requests handled in different
ways according to the use case.
The initial sequence number is proposed by the client (Application)
after the finalization of credential verification. The server (DLT
gateway) MUST respond with the same sequence number to indicate
acceptance.
Hargreaves & Hardjono Expires April 13, 2021 [Page 8]
Internet-Draft ODAP October 2020
The client (application) increments the sequence number with each new
request. Sequence numbers can be reused for retries in the event of
a gateway timeout.
3.6.6. Messages can now be exchanged
Handshaking is complete at this point, and the client (application)
can send ODAP messages to perform actions of DLT resources, which MAY
reference the ODAP Payload field.
3.7. Digital Asset Resource Discovery
Resource discovery is handled by the DLT gateway, a GET request
against the gateway URL with no DLT or resource MUST returns a list
of URLs available to the requester to DLT level. This list is
subject to the access controls above.
DLT Gateways may allow applications to discover URLs they do not have
access to, this should be indicated the free test field, and they
should implement a process for applications to request access.
3.7.1. Format
JSON structure, consisting of a set of responses, each is: URL, free
text field, admin contact
3.8. Accessing Resources via a DLT Gateway
The "Action" field is used to access resources via the gateway. We
suggest these interactions use REST semantics however a detailed API
specification is out of scope of this memo.
In general, we suggest exposing a common subset of functionality via
API using the Action field, augmented with DLT specific or smart
contract specific functionality as needed.
3.8.1. Backward Compatibility
It is also possible to send a fully formatted native message to the
underlying DLT in the Payload field, directed to a resource URL.
This allows existing DLT native code to be ported to ODAP
infrastructures with minimal change.
4. Security Consideration
Although the current interoperability architecture for blockchain
gateways assumes the externalization of the value of assets, as a
blockchain system holds an increasing number of virtual assets it
Hargreaves & Hardjono Expires April 13, 2021 [Page 9]
Internet-Draft ODAP October 2020
becomes attractive to attackers seeking to obtain cryptographic keys
of its nodes and its end-users.
Gateway nodes are of particular interest to attackers because they
enable the transferal of virtual assets to external blockchain
systems, which may or may not be regulated. As such, hardening
technologies and tamper-resistant crypto-processors (e.g. TPM, SGX)
should be used for implementations of gateways [HS19].
Due to the consensus-based nature of the underlying DLT technologies,
gateway responses may be conditional and require verification, for
instance if the DLT is undergoing a byzantine attack at the time of
the request.
The application must evaluate the correctness of responses from the
gateway in context and may need to perform further verification steps
with later ODAP calls. The application may base this evaluation on
the number of DLT nodes the gateway has interacted with in order to
fulfil the request.
5. IANA Consideration
(TBD)
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <https://www.rfc-editor.org/info/rfc2234>.
6.2. Informative References
[HS2019] Hardjono, T. and N. Smith, "Decentralized Trusted
Computing Base for Blockchain Infrastructure Security,
Frontiers Journal, Sepcial Issue on Blockchain Technology,
Vol. 2, No. 24", December 2019,
<https://doi.org/10.3389/fbloc.2019.00024>.
[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>.
Hargreaves & Hardjono Expires April 13, 2021 [Page 10]
Internet-Draft ODAP October 2020
[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939,
September 2010, <https://www.rfc-editor.org/info/rfc5939>.
Authors' Addresses
Martin Hargreaves
Quant Network
Email: martin.hargreaves@quant.network
Thomas Hardjono
MIT
Email: hardjono@mit.edu
Hargreaves & Hardjono Expires April 13, 2021 [Page 11]