Re: [Blockchain-interop] Scope of Work

[Thomas Hardjono <[e-mail]>]

Hi Miguel,

>>> 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.

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).

>>>    - Consensus: no asset transfer occurs without 
>>>      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 [[e-mail]] on behalf of Miguel Correia [miguel.p.correia=[e-mail]]
Sent: Monday, October 19, 2020 10:18 AM
To: [e-mail]
Subject: Re: [Blockchain-interop] Scope of Work

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 <[e-mail]> wrote:
>
>
> 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 [[e-mail]]
> Sent: Monday, October 19, 2020 5:18 AM
> To: Thomas Hardjono
> Cc: [e-mail]
> Subject: RE: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
>
> 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 <[e-mail]>
> Sent: Sunday, October 18, 2020 2:56 PM
> To: Martin Hargreaves <[e-mail]>
> Cc: [e-mail]
> 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.
>
>
> 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 [[e-mail]]
> Sent: Thursday, October 15, 2020 5:09 AM
> To: Thomas Hardjono; Rafael André Pestana Belchior
> Cc: [e-mail]; [e-mail]
> Subject: RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
>
> 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 <[e-mail]> On Behalf Of Thomas Hardjono
> Sent: Tuesday, October 13, 2020 9:43 PM
> To: Rafael André Pestana Belchior <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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.
>
> 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 [[e-mail]]
> Sent: Tuesday, October 13, 2020 4:16 PM
> To: Thomas Hardjono
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Blockchain-interop] Scope of Work
>
> 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:
>> 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 [[e-mail]] on
>> behalf of [e-mail] [[e-mail]]
>> Sent: Tuesday, October 13, 2020 2:45 PM
>> To: [e-mail]
>> Subject: [Blockchain-interop] Scope of Work
>>
>> 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
>
> --
> 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
> [e-mail]
> 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.
> 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.
>
> --
> Blockchain-interop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/blockchain-interop

--
Blockchain-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/blockchain-interop