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

[Venkatraman Ramakrishna <[e-mail]>]

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=