Re: [Sat] App to Gateway interaction --- RE: The chair's proposal to create a terminology draft

[Denis Avrilionis <[e-mail]>]

Dear Claire, Wes
If there is still room for presentations at the interim meeting March 14, I would like to present some work on the phase before starting the execution of SAT-Core flow (what we call "Stage-0” / "pre-transfer" in the mailing list).  
Thank you,
Best Regards,
Denis


> On 8 Mar 2023, at 17:42, Thomas Hardjono <[e-mail]> wrote:
> 
> 
> Thanks Rama,
> 
> The group has discussed the need in Stage-0 for Alice's App1 to somehow communicate with Bob's App2, as part of them agreeing to perform a transfer (and kickstart Stage-1 of SATP).
> 
> Some kind of "transfer context" need to be agreed upon by App1 and App2, and then for this transfer-context to be used in combination with our Session-ID in the SAT-Core flow.  Denis was mentioning this already sometime last year.
> 
> We will need to capture some of these pre-transfer constructs and assumptions (e.g. maybe in the Architecture draft, or even in a separate draft).
> 
> 
> 
> --thomas
> 
> 
> 
> 
> ________________________________________
> From: Venkatraman Ramakrishna [[e-mail]]
> Sent: Wednesday, March 8, 2023 10:23 AM
> To: Thomas Hardjono; Denis Avrilionis
> Cc: Luke Riley; [e-mail]
> Subject: RE: App to Gateway interaction --- RE: [Sat] The chair's proposal to create a terminology draft
> 
> Denis, Thomas: I'm happy to discuss Phase-0 too.
> 
> Rama
> 
> -----Original Message-----
> From: Thomas Hardjono <[e-mail]>
> Sent: 08 March 2023 00:30
> To: Denis Avrilionis <[e-mail]>; Venkatraman Ramakrishna <[e-mail]>
> Cc: Luke Riley <luke.riley=[e-mail]>; [e-mail]
> Subject: [EXTERNAL] App to Gateway interaction --- RE: [Sat] The chair's proposal to create a terminology draft
> 
> 
> [Changing the Subject line to be more appropriate]
> 
> 
> Hi Denis,
> 
>>>> the responsibility for managing the assets including permissions at
>>>> user level should remain between the client app and the network/system.
>>>> We shouldn’t involve gateways in that part, gateways are there to
>>>> execute transfers (instances of execution of SATP).
> 
> Yes agree.
> 
> This is what we call Type-1 API (REST API) for the Client to interact with the Gateway. It's still there in Fig 1 of the SATP-Core draft.
> 
> 
>>>> Hidden behind this discussion are the initiation steps of the protocol.
>>>> I would like to initiate a discussion with a subgroup of people who
>>>> want to dig deeper into that “step 0” before initiating SATP between G1 and G2.
>>>> Would someone like to work with me on that part and present a draft to the group?
> 
> 
> Yes this is a good idea. Happy to help.
> 
> I think there is significant difference between Account-Based networks (e.g. Ethereum) and and UTXO-based networks, because then the App itself will interact differently with the network/ledger.
> 
> 
> 
> --thomas
> 
> 
> 
> 
> 
> ________________________________________
> From: Denis Avrilionis [[e-mail]]
> Sent: Tuesday, March 7, 2023 11:34 AM
> To: Venkatraman Ramakrishna
> Cc: Thomas Hardjono; Luke Riley; [e-mail]
> Subject: Re: [Sat] The chair's proposal to create a terminology draft
> 
> In my opinion, the responsibility for managing the assets including permissions at user level should remain between the client app and the network/system. We shouldn’t involve gateways in that part, gateways are there to execute transfers (instances of execution of SATP).
> 
> Hidden behind this discussion are the initiation steps of the protocol. I would like to initiate a discussion with a subgroup of people who want to dig deeper into that “step 0” before initiating SATP between G1 and G2. Would someone like to work with me on that part and present a draft to the group?
> 
> On 7 Mar 2023, at 16:44, Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>> wrote:
> 
> Denis,
>   I agree with what you say, but where do we specify the list of users (or keys) that are allowed these permissions? In the digital asset structure itself?
> 
> Rafael,
> I think that distinction is important. Aren’t gateways controllers acting on behalf of end users?
> I'd thought of the gateway as possessing a special and circumscribed role: e.g., the gateway, even though it assumes temporary control over an asset, does not possess any privileges to manipulate the state of the asset WITHIN a network. A generic "controller" role will likely possess other privileges.
> But I think we should discuss this further. Maybe define a minimal set of roles that SATP must be cognizant of.
> 
> 
> Rama
> 
> -----Original Message-----
> From: Denis Avrilionis <[e-mail]<mailto:[e-mail]>>
> Sent: 07 March 2023 20:05
> To: Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>>
> Cc: Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Luke Riley <luke.riley=[e-mail]<mailto:luke.riley=[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [Sat] The chair's proposal to create a terminology draft
> 
> IMO for the purpose of SATP we only need to state that the users (Alice/Bob) have roles that allow them to interrupt, refuse, or accept the transfer of the assets (i.e. resulting to rollback or commit of the transfer).
> 
> --
> Denis
> 
> On 7 Mar 2023, at 16:25, Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>> wrote:
> 
> For the purpose of secure asset transfer, shouldn't we treat "owner" and "controller" as synonymous? (One example of where the owner and controller will be different is for digital stock; the owner of the stock can delegate transfer and sale permissions to a broker). The details of permissioning/delegating are always going to be ledger-specific, so SATP can (or ought to) ignore them.
> 
> Rama
> 
> -----Original Message-----
> From: sat <[e-mail]<mailto:[e-mail]>> On Behalf Of Thomas Hardjono
> Sent: 07 March 2023 19:43
> To: Denis Avrilionis <[e-mail]<mailto:[e-mail]>>; Luke Riley
> <luke.riley=[e-mail]<mailto:luke.riley=[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [Sat] The chair's proposal to create a
> terminology draft
> 
> 
> Hi Denis and Luke,
> 
> Denis:
> To my view, SATP deals exclusively with assets that are explicitly owned.
> I tend to believe that this is a hard requirement for SATP, i.e.
> SATP assumes by default that the underlying systems must explicitly
> manage ownership of assets and that asset providers are accountable for the assets they manage.
> 
> The SATP protocol is kickstarted by Alice (the Originator) on network NW1 via an Application (App1) that Alice is driving.
> 
> So Alice must be in control of the private-key associated with the asset on the ledger of NW1. (Alice may our may not be the legal owner of the asset, but she controls the keys/address).
> 
> BTW.  we will need some terminology (even if brief) about things like Asset Definitions (asset profiles), Identifier of an Asset Definition, Issuer of the instance of the asset (confirming to a given asset-profiler), etc.
> 
> 
> 
> 
> Luke:
> *   There is no reference to ownership here. With the implication that a digital asset could be unowned.
> This is more likely on a non-ledger data store in my opinion.
> 
> I think we have been implicitly assuming ownership in our discussions.
> 
> For example, we have been saying that in Stage-0 of the protocol the Gateways G1 and G2 (and their operators) performs several checks/validations:
> 
> (a) Identity of the Originator & Beneficiary (Alice & Bob) -- which is the FATF requirement. The gateways may want to check the person-identity of Alice of Bob, which is possibly an off-chain data/attribute.
> 
> (b) Asset Identifier (of the asset sought to be transferred) -- which is where the Asset Profile and Profile Identifier/Numbering discussion came in.
> 
> (c) Gateway Identity (Operator Identity and device-level identity).
> 
> (d) Network identifier.
> 
> 
> With the implication that a digital asset could be unowned.
> 
> Did you mean an an on-chain asset whose private-key is lost/unrecoverable (e.g. case of the guy who threw away his old laptop containing keys).
> 
> 
> 
> best
> 
> --thomas
> 
> 
> ________________________________________
> From: Denis Avrilionis [[e-mail]<mailto:[e-mail]>]
> Sent: Monday, March 6, 2023 9:48 AM
> To: Luke Riley
> Cc: Venkatraman Ramakrishna; Thomas Hardjono; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> Subject: Re: [Sat] The chair's proposal to create a terminology draft
> 
> A comment on assets persisted on non-ledger data stores: there is ALWAYS an owner if business requirements require explicit management of ownership in all systems (both non-ledger as well as ledger-based).
> 
> To my view, SATP deals exclusively with assets that are explicitly owned. I tend to believe that this is a hard requirement for SATP, i.e. SATP assumes by default that the underlying systems must explicitly manage ownership of assets and that asset providers are accountable for the assets they manage.
> 
> 
> On 6 Mar 2023, at 16:26, Luke Riley <luke.riley=[e-mail]<mailto:luke.riley=[e-mail]>> wrote:
> 
> There are probably 2 or 3 asset related definitions that we need:
> 
> 1.  asset
> 2.  digital asset
> 3.  DLT asset
> 
> I looked into what ISO have and they are:
> 
> 1.  asset: anything that has value to a stakeholder [source ISO/TS
> 19299:2015]  2.  digital asset: asset that exists only in digital form
> or which is the digital representation of another asset [source
> ISO/DIS 22739]  3.  crypto-asset: digital asset (3.20) implemented
> using cryptographic techniques [source ISO/DIS 22739]
> 
> Thoughts:
> 
> *   There is no reference to ownership here. With the implication that a digital asset could be unowned. This is more likely on a non-ledger data store in my opinion.
> *   The crypto-asset definition seems a bit weak. There was no DLT asset definition that I could find.
> *   I Like Rama's suggestion for the blockchain version but it is better to widen it out to all DLTs.
> 
> Regards,
> 
> Luke
> Luke Riley​
> 
> 
> Head of Innovation
> 
> <image616787.png><INVALID URI REMOVED
> _www.quant.network_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=r1mDXzFktk7OyW
> xVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is05Fb6nphe1L9D8vhX
> NPSaRRny72PnJf4DIgWMF96j51&s=UXZsxX7PsE5s6RBI3R3QloJb4-UGmzDXkYhXVfbd2
> DY&e=  >
> 
> [e-mail]<mailto:[e-mail]>
> 
> T: [phone]
> 
> quant.network<INVALID URI REMOVED.
> quant.network_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=r1mDXzFktk7OyWxVu-F
> HM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is05Fb6nphe1L9D8vhXNPSaR
> Rny72PnJf4DIgWMF96j51&s=Qyj6RWicZdSSZbIK_FYHSNPRbk8sUoGSL8wfL7H2Zyo&e=
> 
> 
> 
> <image139184.png><INVALID URI REMOVED
> _twitter.com_quant-5Fnetwork&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=r1mDX
> zFktk7OyWxVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is05Fb6nph
> e1L9D8vhXNPSaRRny72PnJf4DIgWMF96j51&s=SknievpYatT1xXe-ZROW7rAutK2fVdls
> gPhRoEMcCoA&e=  >
> 
> <image551212.png><INVALID URI REMOVED
> _www.linkedin.com_company_quantnetwork_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1
> ZOg&r=r1mDXzFktk7OyWxVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw
> -is05Fb6nphe1L9D8vhXNPSaRRny72PnJf4DIgWMF96j51&s=Qz8wEKzoEFcx3Mt2FNiWU
> ivSYtolLXi-z4ySlyUiyL0&e=  >
> 
> 
> The content of this email is confidential and intended for the recipient specified in message only. It is ​strictly forbidden to share any part of this message with any third party, without a written consent of ​the sender. If you received this message by mistake, please reply to this message and follow with its ​deletion, so that we can ensure such a mistake does not occur in the future.
> ​
> ​
> 
> 
> 
> ________________________________
> From: sat <[e-mail]<mailto:[e-mail]>> on
> behalf of Venkatraman Ramakrishna
> <[e-mail]<mailto:[e-mail]>>
> Sent: 06 March 2023 13:28
> To: Thomas Hardjono <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]><[e-mail]<ma
> ilto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [Sat] The chair's proposal to create a terminology draft
> 
> 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.
> 
> 
> To distinguish a digital asset from any other conventional database record, I think we should also mention its ownership in the definition. How about:
> 
> -- Digital Asset:  A value-bearing data object that is uniquely represented and associated with an unambiguous set of owner identities within a given asset system or network.
> 
> For a blockchain system, we can also add "with an unambiguous trail of ownership from creation to the present".
> 
> What do you think?
> 
> -- Asset Transfer Protocol: Since we have already defined "digital asset", why not just use that term in this definition instead of "value-bearing data object ("asset")"? Also, should we add the following in this definition (since they would apply to any SATP instance):
> * ..... from one network to another via gateways authorized to act on behalf of their respective networks.
> * .....verifiable by an independent authorized 3rd party with access to the gateways' logs.
> 
> If you accept the above, we'll need to define a "gateway" first. How about:
> 
> -- Gateway: A legally authorized device or software agent that is delegated by an asset system to transfer digital assets to another asset system and receive digital assets from another asset system.
> 
> We should also move the "Asset Transfer Protocol" definition to the end as it refers to all the other terms.
> 
> Rama
> 
> 
> -----Original Message-----
> From: sat <[e-mail]<mailto:[e-mail]>> On
> Behalf Of Thomas Hardjono
> Sent: 06 March 2023 18:13
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] Re: [Sat] The chair's proposal to create a
> terminology draft
> 
> 
> I just realized that although some of the SATP Slides discusses the definition of a digital asset, we don't actually have it in the text of our Architecture doc.
> 
> 
> Here is my first cut attempt:
> 
> 
> -- Digital Asset:  A value-bearing data object that is uniquely
> represented within a given asset system or network. [This was in our
> BOF slides]
> 
> -- Asset Transfer Protocol: An interoperability protocol that permits
> the movement of a unique value-bearing data object ("asset") from one
> network to another, while guaranteeing that the data-object is valid
> in one network only at any one time, and that the transfer is
> verifiable by an independent authorized 3rd party. [This was in our
> BOF slides]
> 
> -- Asset Network or System: One or more computer systems that act in unison to maintain the unique state representation of a digital asset.
> 
> 
> 
> 
> best
> --thomas
> 
> 
> 
> 
> ________________________________________
> From: Wes Hardaker [[e-mail]<mailto:[e-mail]>]
> Sent: Friday, March 3, 2023 5:02 PM
> To: Luke Riley
> Cc: Miguel Correia; Thomas Hardjono; Venkatraman Ramakrishna; Denis
> Avrilionis; Wes Hardaker; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Sat] The chair's proposal to create a terminology draft
> 
> Luke Riley <[e-mail]<mailto:[e-mail]>> writes:
> 
> I also agree that creating a terminology document is a good idea. As
> Miguel mentions yes we should utilise those two ISO documents, to
> promote standard alignment.
> 
> Thanks to all those that have suggested pointing at or reusing external vocabulary sets, and I think as the WG discusses this going forward that's definitely something we should consider.
> 
> Having said that, I'll note that SATP is targeting a wider solution than some of those vocabulary sets may be using so we might need to define terms that include the other definitions, but are a super-set.  The obvious example to me is that SATP is supposed to transfer digital assets regardless of the type of storage system on either side of the transaction -- i.e., there may not be a blockchain on one or both sides.
> 
> --
> Wes Hardaker
> USC/ISI
> 
> --
> sat mailing list
> [e-mail]<mailto:[e-mail]>
> INVALID URI REMOVED
> rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fma
> ilman-252Flistinfo-252Fsat-26data-3D05-257C01-257Cluke.riley-2540quant
> .network-257C40d3ef9ebc75424da16308db1e46c098-257C70500bf4d41742598a6e
> b7a550c6d120-257C0-257C0-257C638137061460969454-257CUnknown-257CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-
> 253D-257C3000-257C-257C-257C-26sdata-3DiolUMlYfHnVl2TLe-252BPEEFVFNPt9
> 3jSnbZagYg5arztI-253D-26reserved-3D0&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg
> &r=r1mDXzFktk7OyWxVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is
> 05Fb6nphe1L9D8vhXNPSaRRny72PnJf4DIgWMF96j51&s=KUHB-sDV9wrIZjiZWUM2grw3
> 98G0SeE-BxU0XZ4l3uY&e=
> 
> --
> sat mailing list
> [e-mail]<mailto:[e-mail]>
> INVALID URI REMOVED
> rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fma
> ilman-252Flistinfo-252Fsat-26data-3D05-257C01-257Cluke.riley-2540quant
> .network-257C40d3ef9ebc75424da16308db1e46c098-257C70500bf4d41742598a6e
> b7a550c6d120-257C0-257C0-257C638137061460969454-257CUnknown-257CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-
> 253D-257C3000-257C-257C-257C-26sdata-3DiolUMlYfHnVl2TLe-252BPEEFVFNPt9
> 3jSnbZagYg5arztI-253D-26reserved-3D0&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg
> &r=r1mDXzFktk7OyWxVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is
> 05Fb6nphe1L9D8vhXNPSaRRny72PnJf4DIgWMF96j51&s=KUHB-sDV9wrIZjiZWUM2grw3
> 98G0SeE-BxU0XZ4l3uY&e=
> --
> sat mailing list
> [e-mail]<mailto:[e-mail]>
> INVALID URI REMOVED
> man_listinfo_sat&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=r1mDXzFktk7OyWxVu
> -FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is05Fb6nphe1L9D8vhXNPS
> aRRny72PnJf4DIgWMF96j51&s=rJXIDkOV6t99H9pQKvAxAGRlL01vbCsWHG-mpOkLPFc&
> e=
> 
> --
> sat mailing list
> [e-mail]
> INVALID URI REMOVED
> man_listinfo_sat&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=r1mDXzFktk7OyWxVu-FHM6wafgkdPRwRR-Ae__aieFY&m=uNm5XY8SVIYZ4itEvw-is05Fb6nphe1L9D8vhXNPSaRRny72PnJf4DIgWMF96j51&s=rJXIDkOV6t99H9pQKvAxAGRlL01vbCsWHG-mpOkLPFc&e=
> 
> -- 
> sat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sat