Subject: [Blockchain-interop] Logical sub-phases of Phase-1 of ODAP

From: Thomas Hardjono <[email-masked]>
Date: Mon, 3 May 2021 14:42:09 +0000

Folks,

Looking at Phase-1 of the ODAP protocol, it seems that we may benefit from better clarification of the "sub-phases" within Phase-1.

Also, looking at Phase-1 there seems to be a progression or priority raking of the importance of some tasks (e.g. task B cannot proceed until task A is done).

For example, before gateway G1 and gateway G2 can begin to exchange the asset-profile (of the digital asset to be transferred) and the escrow/lock profile (e.g. config info), the gateways must first discover each other at the network layer and then they must ascertain that G1 and G2 are true gateways (i.e. not fake endpoints pretending to be gateways).

Here is one possible logical arrangement for the progression through Phase-1:

(a) Sub-phase A:   Gateway discovery at the network level and validation that the endpoints represent true gateways (i.e. has the correct gateway capabilities at the device level).

(b) Sub-phase B:  Gateway-ownership validation. Both gateways G1 and G2 must be owned by a legal entity (Virtual Asset Service Provider or VASP). However, different VASPs may be operating out of different legal jurisdictions (e.g. EU, Japan, US). 

This means that Gateway G1 (owned by VASP1) must verify that gateway G2 (owned by VASP2) truly belongs to a legitimate VASP. For example, a VASP should be a registered businesses in a jurisdiction, has a LEI number, etc. etc.

(c) Sub-phase C: Validating the capability/capacity to handle digital asset as defined by the Asset Profile.  This is not just the technical capabilities, but also legal capability to intake/absorb the digital asset.

(d) Sub-Phase D: Validating the originator and beneficiary of the asset transfer. This is what is known as the funds Travel Rule (which the banking sector have observed since the late 1990s).

Since we cannot solve many of these questions (i.e. outside the purview of the IETF), perhaps we could make some assumptions and define some REST APIs for each of these off-chain services (e.g. assume API_check_travel_rule() to validate the travel rule data).

We could then use the output (e.g. output_string_x ) from these assumed APIs as part of the ODAP flows and Crash Recovery logging flows. 

Any thoughts?

-- thomas --

---

From: Rafael Belchior <[email-masked]>
Date: Mon, 03 May 2021 16:24:34 +0100

Hello Thomas,

A 2021-05-03 15:42, Thomas Hardjono escreveu:
> Folks,
> 
> Looking at Phase-1 of the ODAP protocol, it seems that we may benefit
> from better clarification of the "sub-phases" within Phase-1.
> 

This makes sense. The first phase sets up the stage for the whole flow. 
Probably, the different profiles (Credential Profile, Payload 
Profile,Application Profile, Access_control_profile?, logging profile ) 
should be set here.

> Also, looking at Phase-1 there seems to be a progression or priority
> raking of the importance of some tasks (e.g. task B cannot proceed
> until task A is done).
> 
> For example, before gateway G1 and gateway G2 can begin to exchange
> the asset-profile (of the digital asset to be transferred) and the
> escrow/lock profile (e.g. config info), the gateways must first
> discover each other at the network layer and then they must ascertain
> that G1 and G2 are true gateways (i.e. not fake endpoints pretending
> to be gateways).
> 
> (a) Sub-phase A:   Gateway discovery at the network level and
> validation that the endpoints represent true gateways (i.e. has the
> correct gateway capabilities at the device level).

This includes device attestation and using @Shipping's work on the 
discoverability of gateways. Device attestation most likely requires 
vendor-specific APIs. Discoverability uses a DNS-based method 
(correct?).
Thus these could use "assumed" APIs.

> 
> (b) Sub-phase B:  Gateway-ownership validation. Both gateways G1 and
> G2 must be owned by a legal entity (Virtual Asset Service Provider or
> VASP). However, different VASPs may be operating out of different
> legal jurisdictions (e.g. EU, Japan, US).
> 
> This means that Gateway G1 (owned by VASP1) must verify that gateway
> G2 (owned by VASP2) truly belongs to a legitimate VASP. For example, a
> VASP should be a registered businesses in a jurisdiction, has a LEI
> number, etc. etc.

Usesthe Credential Profile.

> 
> 
> (c) Sub-phase C: Validating the capability/capacity to handle digital
> asset as defined by the Asset Profile.  This is not just the technical
> capabilities, but also legal capability to intake/absorb the digital
> asset.

Uses Payload Profile/Asset Profile

> 
> (d) Sub-Phase D: Validating the originator and beneficiary of the
> asset transfer. This is what is known as the funds Travel Rule (which
> the banking sector have observed since the late 1990s).

Uses Application Profile

I suppose that then we would need a phase E, in which gateways agree on
logging profile for accountability/crash recovery. Perphaps agreeing on 
the logging profile could also occur on phase B (right after 
gateway-ownership validation) so that posterior validations can be 
logged.

Cheers,
R

> 
> Since we cannot solve many of these questions (i.e. outside the
> purview of the IETF), perhaps we could make some assumptions and
> define some REST APIs for each of these off-chain services (e.g.
> assume API_check_travel_rule() to validate the travel rule data).
> 
> We could then use the output (e.g. output_string_x ) from these
> assumed APIs as part of the ODAP flows and Crash Recovery logging
> flows.
> 
> Any thoughts?
> 
> 
> 
> -- thomas --

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/