Re: [Sat] Question about asset-identifiers

Thomas Hardjono <hardjono@mit.edu> Thu, 21 March 2024 18:33 UTC

Return-Path: <hardjono@mit.edu>
X-Original-To: sat@ietfa.amsl.com
Delivered-To: sat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77A5C14F684 for <sat@ietfa.amsl.com>; Thu, 21 Mar 2024 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.758
X-Spam-Level:
X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwemmBSj9mr9 for <sat@ietfa.amsl.com>; Thu, 21 Mar 2024 11:33:01 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2109.outbound.protection.outlook.com [40.107.220.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEEEC14F60E for <sat@ietf.org>; Thu, 21 Mar 2024 11:33:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q+2D23eCdLN8x+GPkc9KiJ6wAtNBnr/d+P3QjeY1VcsOT9Nqvp1X+kv1+OtgvqY+HFVpZiUFB4bHraPqzJyHg9oopgEFUbXR1S96iBpikmPoo/ZjSQktjI3dkGjSfxPze3GzfZaR4UU6r1XXD9sGEOeLhtALudxC0fWRGIdQ8TOKii05hnxJFCC7ZuOklhrLn2VZJ1njLTTxCfIXnqOXbbZAgaPLVNmctlwVxGKrKwJXzfNjxo0W5d2Jt/lHzZxzS0ILGyV1im1p2cec1dexX34Qlae+nwGJVMSaAkWLrtp4fZ8e8wIrRFpaHxhNOGP7x/lMReFDuIWuze+ooG0VKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sauYYnMVPVy5S4+idiZOuHjKNT5iDel6KDVq8iqIr7w=; b=Wf/HYnoTH5i+40WKXLKy7yMAN3BYuya6Pk12g6qTmwRKIEuwb5XcdkUL7rKvNFWRnXqd6uSNh+5wdaF+QIZNttl86lDjTPDQDRNo3U+im30H+nPf8vq/6ZGcLSs4hnZ9FL3vSSgaeD3q9Fz7yenTFX6sHAnQLNBm4bmUNfpl/Yg/kzz1F/tp80ZMLzPWxz5UgQcZktL3jbTvrfNW02byC9mUCMC7BSpWNTI0tMX4/6TVt/tPjFP1gDJXXiVYl12XOb+/copOjge6zFNtAj4WA272xE/Las4bYhuMwxoN36d6c/csroKKmK3WAfUH8rwxdAc7m4+J6tJ5fKl9aZzJtA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sauYYnMVPVy5S4+idiZOuHjKNT5iDel6KDVq8iqIr7w=; b=q+CxTJ+adYL2PgM+Yu85rv7j+1DrAc1jl5biYc7Yz3ZxzzSRqCDXj0HtBYiVkg24qmO4ymk0jSd3gMKnUsiaUbBWeHsOQBhUwqkh7ahcwTS10rYUHWfm2FxrpUI7z9jjPqqSGcjUk8NwLZJ4k65tSKaRF8i/l8HVsbq/gSkFumY=
Received: from DM6PR01MB4395.prod.exchangelabs.com (2603:10b6:5:7a::16) by PH0PR01MB7994.prod.exchangelabs.com (2603:10b6:510:28a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.30; Thu, 21 Mar 2024 18:32:59 +0000
Received: from DM6PR01MB4395.prod.exchangelabs.com ([fe80::e4f9:514d:5169:6582]) by DM6PR01MB4395.prod.exchangelabs.com ([fe80::e4f9:514d:5169:6582%5]) with mapi id 15.20.7386.025; Thu, 21 Mar 2024 18:32:59 +0000
From: Thomas Hardjono <hardjono@mit.edu>
To: Denis Avrilionis <denis@compell.io>
CC: Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt>, "sat@ietf.org" <sat@ietf.org>
Thread-Topic: [Sat] Question about asset-identifiers
Thread-Index: AQHae5E/9oDxzqk1B0i9Gh+RYpfq47FCMuQAgAAFZjKAAD/egIAACs9d
Date: Thu, 21 Mar 2024 18:32:58 +0000
Message-ID: <DM6PR01MB4395DD947CA72B95AA5B4B7CCB322@DM6PR01MB4395.prod.exchangelabs.com>
References: <DM6PR01MB43958C3D102A6332CAE513BACB322@DM6PR01MB4395.prod.exchangelabs.com> <DA90D263-5675-4779-916C-99E5179D0A4F@compell.io>
In-Reply-To: <DA90D263-5675-4779-916C-99E5179D0A4F@compell.io>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=mit.edu;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR01MB4395:EE_|PH0PR01MB7994:EE_
x-ms-office365-filtering-correlation-id: f3f890de-1025-4031-37de-08dc49d55565
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: N8w3PSjNzwXaadsl7qmrGDWiR2MUsJe0p1arg6ooTk48aDcsK8Jf4QhGQ1hiF4Pytwrqm1jvxbl6s/EJESMBhsmT0ztE9EJkwL3hJippV59QRbALVETWZI3FpKwyyzV/2DSOjDK2dstAunnsf6mW8VxxIGnV+JYBj9MS8xhqK9m9XW/c/dYFrMBpIqAwyj13ISXrWdac25PePAv49buQWbSu2fyDntw8OgMsuLnv6ORg2iITxdtWHrR8SJU+Pn5f7grgEHiyhN8aKig3EpUsE4I9QqbHXOeKXle4sg+j4tjSaMUeUqakmHQ9kc3gvSFFq3X5euLLbFef0BNImUE19rlvsPPvaYEogItav7q7uJc9dUYJ43+66evEh+uufLTHXvD7gz1N8gw550gWlNiP4OKy2vb+L53HjFB7arVfUMpJFJQGOOVpeOuvIE6K1TMsyH0jdXJF4aEeTiXYMVIWGYVqJzKON6YxpX5cHGUv0BjMSmJrXcOGgFXalJDFtg6U1u4DLxweD5RRuPhCWK6OeGQtj9tCjKTyepa2cX4PTmhJNFdUFF94uoy+hY8OI8W6Ay2iKTBiVAg7L3mCHnjDLEHBKJixKqMeJWsGcdRf9LnaiymSWE7bYHb3WbYrwAnh2qB+FYKrn4h8bGqogbKJyxvYEWOzabVkaggxeTfhHm6owHjHXocDlfMk06sq/NHE
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR01MB4395.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(366007)(1800799015)(38070700009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: deH/eWiKjvLF95Kj/iglBamDvVToYfdEClABgqGEAbInRjX76HmKhLJW4J4Z2p2YzEaU341QN1QPdZ5BcZvdBLXsBi+40eT66GLKvn66kmCckZjCGvloj9bT7ujqxjX5foCMkn8PT6vrqENavYcIbj2sIgpkj58sk7Hpr/uc03dtZxPCBjWCvISGiYS1DtROtv8dCLQ0ex0qp/gIuUksS4IRypRyIYwja5Z8J8LDr2xBCr4OOUkiYYPBFCDlKBhgD3D+Q1E+P6Hzl70V+z+Sm35F1oZAGK4rfmaQRQ8Q/aRYhFwz/jE/zKfOI/o6aHKsKviKK4U9FjjYP4t2Fz5sxGLHyyhPful4DC8ASwwEdflwKDO3gZa6VFH1kt1SBZtFcb4nvb4ML+g41pDT+3bLLvo97FlxMBBQG8DtldvUUzRI6/Wvmqb2inSmLpT7cAs7vXahbyXaX5b7jdmg7nTE3lEX6H2y1Q0PKFEIK/6ZcvjF0wBULuWKh8PICxOWq+0kUZkQVSMOLlH/Id3Eww4jcxVSveXtI7i5ZnmD5Wmz+XdTKQwCHbFi7SIEO3Zz6Uf98fLygaDpXmj2TWYmyE/x4pKQ7N/pQtRd1QCDaI1e/tGB+grL3k+ieOgUm8BwnjtPC4OLvRz4DB1lzfXddY5Alah31mpLlAKek5CMbSbziPZaZx6U8fvtCjcgM66IDYXre91ak9i5yUYWtjwEVAGLuWa7wHy78yBMwbhEjNaTrwxQV70UWXkPuY9XuGnDG9s7xt2eexa7D7vIYHYPp70gieB7prDShoJAcJNhN2gTn4vEW/bcqpqJuf+BF4g46k+i6FDkpAokRCl/2pYklK348fmMUp6nIjNggPqfqxCQmGTOV08j1tKSgmN9quEzo+EMo5s5pAWigKEFX5XOt/k9/0rX9xdAJqqlbST0kqp9NlFu3rtjeG8EDgo905JZacSK6H0c2bpdKERedQSXIhi/6jFukLOdmPGgb213ajsfrDw3R9p1Zy/yPcrWbGl64zX8lrYg710u6uEOUq8V2jpt1GiFhjIADX5DjUz99RTvL6Jpn/iepZG1kWfDnkjrYuxPDn3L8fKVxx+Afhq6kXv9paWM8g8sBqkw5jLfdYXwJ5n0pHYRn/tUy7AN1GiA0QVZISNUST3mNlr4KHIIz4FdaAJvQD1wS7Q7/sN02yqfLmlfZu81/L696z7vKFkJxb1jOQn0AJTnnr8o+zZNJxa7f6b3kNIDV/3owDnAPk1ZjmV51kvv8avlkDEh7NOuF1eqrqYKmTbyb+kpfh8/jkVIyLtqUwcGY0Atm5hOXAFlQ37okgLniA/+q/ZqtSFwg8IyljrV3j9EHwMcT8OXqI3C5pmxV2jqeEpwz/Mnq/1xILtt2PzLR+1tGLO0ReKQ1qH0i9GbiJSDF9UI+/NpvAus/7r10jPKmzdpCZ4UGo5ijkjBNsBPYqfGpDsMWDOBHvh1XboBeLP0UkMgYtad/SuVzLUUEKHv7jwhKuzb1xwN5RvUpon0d8RfVorQI55tNNJaSq9dAQr5H+Gyy+hVJW67HCqinhzavLJU9YAyt97xGo/sFfssdPTEjYh5ewCH4+VDLXQt99x+KwIxKssvxnCuqa2Tmna0a74uLQPz02L5MkMbs6Tc0Fv4vMyESDptTy6O
Content-Type: multipart/alternative; boundary="_000_DM6PR01MB4395DD947CA72B95AA5B4B7CCB322DM6PR01MB4395prod_"
MIME-Version: 1.0
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR01MB4395.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3f890de-1025-4031-37de-08dc49d55565
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2024 18:32:58.9036 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3ERVttcOvj1mExWxkHkqUCa1jOn360yvtNvs2YuuPh75ctVhKDJE7gsM2fRax1HG7eiuAj4edDS7JZSmPGgOmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR01MB7994
Archived-At: <https://mailarchive.ietf.org/arch/msg/sat/rtqs_EuFuW-k4qrzdn4pgbS5ryk>
Subject: Re: [Sat] Question about asset-identifiers
X-BeenThere: sat@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "The purpose of this mailing-list is to discuss the secure asset transfer \(SAT\) protocol and related aspects." <sat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sat>, <mailto:sat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sat/>
List-Post: <mailto:sat@ietf.org>
List-Help: <mailto:sat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sat>, <mailto:sat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 18:33:05 -0000

Thanks Denis,

Yes agree.

The question is more about whether the asset-identifier string from NW1 should be recorded (as “dumb” payload or log informastion) into NW2, independent of the actual asset-addressing scheme used in NW2.

The purpose is for the legal/audit information about which assets arrived (departed) and from which networks.

So, for example, in NW1 the asset-identifier structure could be a full DID. Whereas in network NW2, the asset-identifier could be just a 256bit string.

Thus, the question is whether NW2 should keep a copy of the full DID (e.g. in the blocks of its ledger) for regulatory reasons, even though NW2 may not understand the DID structure.


--thomas



From: Denis Avrilionis <denis@compell.io>
Date: Thursday, March 21, 2024 at 1:46 PM
To: Thomas Hardjono <hardjono@mit.edu>
Cc: Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt>, sat@ietf.org <sat@ietf.org>
Subject: Re: [Sat] Question about asset-identifiers
Dear Thomas, Rafael,
We should take in account the possibility for a network to define IDs that are specific to the structure of the network and may not be transferable to another network. Suppose for example CAIP-19 type of identification where the smart contract that manages the identification of the asset is part of the ID. In such cases it may not be possible to use the sand ID in the target network. I believe we should assume that the scope of the asset ID may be limited to the scope of a specific network. The ID resolution may need navigating in a chain of IDs from the very first network that created the asset to the latest network that currently hosts the asset.

Hope this helps
--
Denis


On 21 Mar 2024, at 16:01, Thomas Hardjono <hardjono@mit.edu> wrote:

Hi Rafael,

I think this could be an option (flag) that could be negotiated between G1 and G2 in the setup stage Stage-0.

So, for example, G1 could request to G2 that “privacy-preserving identifiers” be used in the current transfer.

If the users (asset owners) are not concerned about privacy, then this option could be turned-off (i.e. G1 does not request this from G2 during Stage-0).


--thomas



From: Rafael Belchior <rafael.belchior@tecnico.ulisboa.pt>
Date: Thursday, March 21, 2024 at 9:38 AM
To: Thomas Hardjono <hardjono@mit.edu>
Cc: sat@ietf.org <sat@ietf.org>
Subject: Re: [Sat] Question about asset-identifiers

Hello Thomas,

Is there a possibility that the asset on NW02 preserves its original ID (DAI01)? This would eliminate the issues you are describing. We could also create a history of the IDs the asset has on the proofs that are returned from the gateways (to ensure traceability).

Rafael

A 2024-03-21 15:19, Thomas Hardjono escreveu:



Folks,



Earlier this week I received a question about SATP-core, specifically about digital asset identifiers in the origin network (NW1) and in the destination network (NW2).



The digital asset identifier (DAI) is described very briefly in Section 5.2.3 of draft-core-03 as a UUID.



The question looks simple, but has some twists related to traceability of asset transfers (i.e. regulated assets and taxation) and privacy:



-- Assume the digital-asset is recorded in NW1 (i.e. in the ledger or database) as having an identifier DAI01.  After a successful transfer to NW2, the asset is assigned a new identifier DAI02 in NW2.



-- Question: should NW1 be aware of the new identifier DAI02 in NW2?   (for example, the new identifier DAI02 is reported back from gateway G2 to gateway G1 within the ACK-Final-Receipt message (message 3.7 of draft-core-03)).



-- The implication concerns privacy:  if the new identifier DAI02 is also copied (recorded as plaintext data) in NW1, this may permit other participants (other asset holders) in NW1 to know the new owner of the asset in NW2.





My response was that only the hash-of-DAI02 should be recorded in NW1.



So, the ACK-Final-Receipt message sent from gateway G2 to G1 should have the following parameters (where these will be recorded as data onto NW1 by G1):



Identifier of G1 and G2 (who handled the transfer instance).

The network identifier NW2 (to where the asset was transferred).

The asset identifier DAI01 (which is already known in NW1).

The hash of the asset identifier DAI02 (as it is known in NW2).

Date/timestamp.





As a corollary, when gateway G2 mints and assigns the new asset in NW2 (i.e. assign asset to Bob in NW2 immediately following the Commit-Final-Assertion message 3.5), gateway G2 should also record the hash of identifier DAI01 to NW2:



Identifier of G1 and G2 (who handled the transfer instance).

The network identifier NW1 (where the asset originated from).

The asset identifier DAI02 (the new identifier in NW2).

The hash of the asset identifier DAI01 (as it was known in NW1)

Date/timestamp.





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/
--
sat mailing list
sat@ietf.org
https://www.ietf.org/mailman/listinfo/sat