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