Subject: [Blockchain-interop] Scope of Work

From: <[email-masked]>
Date: Tue, 13 Oct 2020 18:45:15 +0000

Hi all, great meeting you all in today's kickoff call!

Regarding the scope: I was wondering whether we should also include other interoperability issues apart from asset transfers, such as referencing data between blockchains (or from a blockchain to a legacy system)?

The reason why I'm asking is because a new DLT law is expected to enter into force in Switzerland next year, which will require that for all DLT-based financial instruments corresponding investor documentation (e.g. prospectus) shall be made available either directly on the given ledger or by referring to an outside data storage (which could be a legacy system as mentioned on slide 10 point 2). The latter case obviously creates an interoperability problem. So far the legislator has only outlined that there needs to be a unique pointer/identifier (e.g. a hash of the document), to ensure integrity of the accompanying external documentation. But apart from that there are currently no specific technical guidelines on how an interoperable on-/off-ledger pointer mechanism shall work. IMO our IETF working group could be a great platform to discuss and provide some guidance. What do you think?

Best regards
Aetienne

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 13 Oct 2020 19:47:57 +0000

Hi Aetienne,

>> Regarding the scope: I was wondering whether we 
>> should also include other interoperability issues apart 
>> from asset transfers, such as referencing data 
>> between blockchains (or from a blockchain to a legacy system)?

Yes, for sure -- the model describes in the architecture draft calls these references and data (on-chain and off-chain) generically as "blockchain resources".

For example, if a third party entity is used to "price"  a virtual asset (e.g. economic pricing or estimate done by a bank or FI) prior to the asset transfer, then the transfer-payload between G1 and G2 could (must) include a link (e.g. URL or hash) to the claim signed by the  third party.

This means that G1 must sign the payload using its entity public key pair (not the transaction public key pair).  Here G1 (i.e. the VASP owner of G1) is essentially asserting the truthfulness of the link to the resource.

Best

-- thomas --

________________________________________
From: Blockchain-interop [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Tuesday, October 13, 2020 2:45 PM
To: [email-masked]
Subject: [Blockchain-interop] Scope of Work

Best regards
Aetienne

---

From: Rafael André Pestana Belchior <[email-masked]>
Date: Tue, 13 Oct 2020 21:16:32 +0100

Hello All,
Great to e-meet you.

The fact that G1 signs the payload using its key-pair is a good start to 
ensure accountability. We need to discuss if the protocol should assure 
accountability in case of dispute, or if it suffices to coordinate 
communication.

Cheers,
--rafael

A 2020-10-13 20:47, Thomas Hardjono escreveu:
> Yes, for sure -- the model describes in the architecture draft calls
> these references and data (on-chain and off-chain) generically as
> "blockchain resources".
> 
> For example, if a third party entity is used to "price"  a virtual
> asset (e.g. economic pricing or estimate done by a bank or FI) prior
> to the asset transfer, then the transfer-payload between G1 and G2
> could (must) include a link (e.g. URL or hash) to the claim signed by
> the  third party.
> 
> This means that G1 must sign the payload using its entity public key
> pair (not the transaction public key pair).  Here G1 (i.e. the VASP
> owner of G1) is essentially asserting the truthfulness of the link to
> the resource.
> 
> Best
> 
> 
> -- thomas --
> 
> 
> 
> From: Blockchain-interop [[email-masked]] on
> behalf of [email-masked] [[email-masked]]
> Regarding the scope: I was wondering whether we should also include
> other interoperability issues apart from asset transfers, such as
> referencing data between blockchains (or from a blockchain to a legacy
> system)?
> 
> The reason why I'm asking is because a new DLT law is expected to
> enter into force in Switzerland next year, which will require that for
> all DLT-based financial instruments corresponding investor
> documentation (e.g. prospectus) shall be made available either
> directly on the given ledger or by referring to an outside data
> storage (which could be a legacy system as mentioned on slide 10 point
> 2). The latter case obviously creates an interoperability problem. So
> far the legislator has only outlined that there needs to be a unique
> pointer/identifier (e.g. a hash of the document), to ensure integrity
> of the accompanying external documentation. But apart from that there
> are currently no specific technical guidelines on how an interoperable
> on-/off-ledger pointer mechanism shall work. IMO our IETF working
> group could be a great platform to discuss and provide some guidance.
> What do you think?
> 
> Best regards
> Aetienne

-- 
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: Thomas Hardjono <[email-masked]>
Date: Tue, 13 Oct 2020 20:42:49 +0000

Thanks Rafael.

As I mentioned, maybe there will need to be a kind of "payload profile" that defines the meaning of the component/part of the payload according to the type of asset and policies/conditions. 

This profile (specification) would include links to the resources (off-chain, or on-chain on ledger L1) that must be delivered from G1 to G2 in order to permit G2 to evaluate and accept the payload.

So for example, if the virtual asset was stablecoin X backed by some securities, then the "payload profile for X" specification may mandate inclusion of a URL to the signed securities (i.e. digitized securities). The profile may even include the Jurisdictions where the profile is honored.

Just a thought.

-- thomas --

________________________________________
From: Rafael André Pestana Belchior [[email-masked]]
Sent: Tuesday, October 13, 2020 4:16 PM
To: Thomas Hardjono
Cc: [email-masked]; [email-masked]
Subject: Re: [Blockchain-interop] Scope of Work

Hello All,
Great to e-meet you.

Cheers,
--rafael

---

From: Martin Hargreaves <[email-masked]>
Date: Thu, 15 Oct 2020 09:09:24 +0000

Hi both,

I'm keen on this approach, it lets us have a well-bounded scope for the coordination of communication, and a clear framework for creation of profiles. I suspect some profiles will require significant domain expertise, particularly if the profile integrates existing domain specific data standards (e.g. ISO20022, FIX or a host of others). I think allowing industry groups to become compliant by creating profiles should provide a level of flexibility that can accelerate adoption of the underlying protocol.

All the best,

Martin

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Tuesday, October 13, 2020 9:43 PM
To: Rafael André Pestana Belchior <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

[EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognise the sender and know the content is safe.

Thanks Rafael.

Just a thought.

-- thomas --

Hello All,
Great to e-meet you.

The fact that G1 signs the payload using its key-pair is a good start to ensure accountability. We need to discuss if the protocol should assure accountability in case of dispute, or if it suffices to coordinate communication.

Cheers,
--rafael

A 2020-10-13 20:47, Thomas Hardjono escreveu:
>>> referencing data between blockchains (or from a blockchain to a
>>> legacy system)?
>

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

--
Blockchain-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/blockchain-interop
This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 18 Oct 2020 13:55:55 +0000

Hows this for a definition of an asset-profile:

Asset profile: The set of information and resources describing a virtual asset, including the asset name/code, issuing authority, denomination, jurisdiction, and the URLs and mechanisms to validate the information. The asset profile is independent from the specific instantiation of the asset (on a blockchain and otherwise) and independent from the asset ownership information.

The basic idea is that the gateway transfer protocol should work for any number of asset-profiles.

-- An asset-profile should have all the relevant links/URLs to permit anyone to validate it. Kind of a "metadata" (e.g. in JSON) fully describing a virtual asset.

-- For non-private assets, anyone should be able to validate the statements or assertions stated in the asset-profile.

-- An asset-profile should not incorporate any ownership information (i.e. ownership of instances of the asset).

-- thomas --

________________________________________
From: Martin Hargreaves [[email-masked]]
Sent: Thursday, October 15, 2020 5:09 AM
To: Thomas Hardjono; Rafael André Pestana Belchior
Cc: [email-masked]; [email-masked]
Subject: RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

Hi both,

All the best,

Martin

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Tuesday, October 13, 2020 9:43 PM
To: Rafael André Pestana Belchior <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

Thanks Rafael.

Just a thought.

-- thomas --

Hello All,
Great to e-meet you.

Cheers,
--rafael

---

From: Martin Hargreaves <[email-masked]>
Date: Mon, 19 Oct 2020 09:18:13 +0000

I like that, I think that checking for compatible profiles on the application and gateway sides is a key validation. Do we also need a naming scheme or identifier format for asset profiles / resource profiles?

Looking at the section on negotiation of security protocols and parameters, should we also encode this as a set of authorisation profiles? This would allow easy referenceability for common configurations, and allow follow-on work to create new security profiles (e.g. a PQ profile).

Best,

Martin

-----Original Message-----
From: Thomas Hardjono <[email-masked]>
Sent: Sunday, October 18, 2020 2:56 PM
To: Martin Hargreaves <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

-- thomas --

Hi both,

All the best,

Martin

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Tuesday, October 13, 2020 9:43 PM
To: Rafael André Pestana Belchior <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

Thanks Rafael.

Just a thought.

-- thomas --

Hello All,
Great to e-meet you.

Cheers,
--rafael

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 19 Oct 2020 13:53:13 +0000

Hi Martin,

>>> I like that, I think that checking for compatible profiles on 
>>> the application and gateway sides is a key validation. 

Yes, good idea -- Gateways G1 and G2 need to verify that they are both referring to the same asset-profile (independent of the actual instances of the asset being transferred, and independent who is the current owner of those instances).

The asset-profile could be a signed JSON file that lists factual assertions about the virtual asset and links to verify these assertions.  Something like:

-- Profile name/identifier

-- Asset code/number (e.g. “USDT, “WIR”, etc.).

-- Asset issuing authority (e.g. “EU ECB”, “DTCB NYC”, etc.) and jurisdiction.

-- URL to validate the above.

-- Signature of profile author (nb. author could be issuing authority).

-- etc.

>>> Do we also need a naming scheme or identifier format 
>>> for asset profiles / resource profiles?

Yes, I think we do need this.  Any suggestions?

>>> Looking at the section on negotiation of security 
>>> protocols and parameters, should we also encode this 
>>> as a set of authorisation profiles? 
>>> This would allow easy referenceability for common 
>>> configurations, and allow follow-on work to 
>>> create new security profiles (e.g. a PQ profile).

Good idea. Having pre-baked authorization profiles would help speed-up transfers. 

-- thomas --

________________________________________
From: Martin Hargreaves [[email-masked]]
Sent: Monday, October 19, 2020 5:18 AM
To: Thomas Hardjono
Cc: [email-masked]
Subject: RE: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

Best,

Martin

-----Original Message-----
From: Thomas Hardjono <[email-masked]>
Sent: Sunday, October 18, 2020 2:56 PM
To: Martin Hargreaves <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

-- thomas --

Hi both,

All the best,

Martin

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Tuesday, October 13, 2020 9:43 PM
To: Rafael André Pestana Belchior <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Blockchain-interop] Scope of Work

Thanks Rafael.

Just a thought.

-- thomas --

Hello All,
Great to e-meet you.

Cheers,
--rafael

---

From: Miguel Correia <[email-masked]>
Date: Mon, 19 Oct 2020 15:18:09 +0100

Hi,

All this looks great!

I was analysing the protocol and two questions come to mind:

- what are the properties we aim to guarantee for asset transfer? I guess we need something like (very draftish):
	- Non-triviality: no asset transfer occurs if its owner does not require that transfer.
	- Consensus: no asset transfer occurs without agreement from G1 and G2.
	- Termination: asset transfer is concluded when the asset no longer exists in B1 and is represented in B2.

- what are the failure assumptions? Is it possible for G1 and G2 to fail during the process? If they fail, do we assume they later recover?

I need this kind of details to check the correctness of the asset transfer protocol. 

Best,
Miguel

> On 19 Oct 2020, at 14:53, Thomas Hardjono <[email-masked]> wrote:
> 
> 
> Hi Martin,
>

---

From: Martin Hargreaves <[email-masked]>
Date: Mon, 19 Oct 2020 14:19:59 +0000

Hi Thomas,

> >>> I like that, I think that checking for compatible profiles on the
> >>> application and gateway sides is a key validation.
>
> Yes, good idea -- Gateways G1 and G2 need to verify that they are both
> referring to the same asset-profile (independent of the actual instances of
> the asset being transferred, and independent who is the current owner of
> those instances).
>
> The asset-profile could be a signed JSON file that lists factual assertions
> about the virtual asset and links to verify these assertions.  Something like:
>
> -- Asset code/number (e.g. "USDT, "WIR", etc.).
>
> -- Asset issuing authority (e.g. "EU ECB", "DTCB NYC", etc.) and jurisdiction.
>

I think that works well for digital assets, and should work for most other resource types (e.g. provenance or ESG data). We can certainly test it against the different types of asset group members know about to validate it further.

> >>> Do we also need a naming scheme or identifier format for asset
> >>> profiles / resource profiles?
>

We currently have odapres and odapclient (although we could well change that one), so:

Odapresprofile for a resource profile, and odapauthprofile for an authorization profile? Open to suggestions!

> >>> Looking at the section on negotiation of security protocols and
> >>> parameters, should we also encode this as a set of authorisation
> >>> profiles?
> >>> This would allow easy referenceability for common configurations,
> >>> and allow follow-on work to create new security profiles (e.g. a PQ
> >>> profile).
>
>

Great, I'll include this in the next draft.

Best,

Martin

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 19 Oct 2020 14:41:53 +0000

Hi Miguel,

>>> - what are the properties we aim to guarantee for asset transfer? 
>>> I guess we need something like (very draftish):
>>>

Yes is this needed.  One of the challenges faced today by VASPs is in obtaining consent from the both the Originator (Alice) and Beneficiary (Bob).  

Because we are working at a couple of layers below the “asset layer” and “consent layer”, we have to assume that G1 and G2 have obtained the necessary consent (i.e. consent has occurred before G1 and G2 got involved).

>>>      agreement from G1 and G2.

This is part of Phase 1 of the gateway protocol. G1 and G2 must agree that they want to talk to each other, that they are implementing the same transfer protocol.  I’d like to throw in gateway device-attestations, but we can leave that for later :-)

>>>    - Termination: asset transfer is concluded when 
>>>      the asset no longer exists in B1 and is represented in B2.

Some form of standardized evidence/proof is needed that is meaningful to (a) the asset-profile and (b) to the system behind G1 and G2 (i.e. is the system a blockchain, DLT or even a Legacy system).

>>>  what are the failure assumptions? 
>>>  Is it possible for G1 and G2 to fail during the process? 
>>>  If they fail, do we assume they later recover?

This is perhaps one key aspect of the protocol design. We could aim for the ACID properties, but perhaps atomicity and consistency would be a priority (I’m assuming a blockchain systems behind G1 and G2 provides durability).  

Best

-- thomas --

________________________________________
From: Blockchain-interop [[email-masked]] on behalf of Miguel Correia [miguel.p.correia=[email-masked]]
Sent: Monday, October 19, 2020 10:18 AM
To: [email-masked]
Subject: Re: [Blockchain-interop] Scope of Work

Hi,

All this looks great!

Best,
Miguel