Re: [Sat] Views

Hello Rama,
Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct?

Are these additional functionalities and changes to the security model desired to be part of the core protocol or particular instantiations of the gateway (eg plugins)?

Rafael 

> On 21 Mar 2023, at 11:26, Venkatraman Ramakrishna <vramakr2@in.ibm.com> wrote:
> 
> 
> David,
>  
> Sorry for the inordinate delay in responding to you on this topic. (At least it was not pressing, as the “view” drafts are presently not within the SATP scope.)
>  
> Yes, supporting Views (and View Addresses) is meant to be an additional function for the gateways. I don’t recall how well this is sketched out in the drafts I linked to, but there is more work required at G2 in a view request-response protocol. G1 simply communicates messages back and forth within minimal processing (assuming the address of G2 is embedded within the View Address) whereas G2 must submit a request and collect a response from its backing network just like G2 collects evidence for a minting in SATP. I’ll try to work this out later once the SATP is more or less crystallized, but I think supporting views and addresses will require relatively minor augmentations to the features that the gateways must anyway implement for SATP.
>  
> There is a basic security problem that arises in view request and processing, but the solution for this is built into the end-to-end protocol (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-data-sharing/) in the following ways:
> The gateway (G2 specifically) is not trusted either for integrity or confidentiality purposes: it simply returns a proof generated by N/W2, and it does not have the authority (or capability) to unilaterally generate a proof that G1 or N/W1 will accept. In this respect, the trust model is different from what the SATP currently assumes.
> The network being requested for a view (N/W2) will run an access control check before sending a response. If N/W2 is a blockchain/DLT, for example, this will be a consensus-driven decision executed through a smart contract. The right “proof” can’t be generated unless this access control check is passed by a quorum of honest peers.
> I can’t think of other security issues. Do you see anything that is not covered here?
>  
> Regarding the utility of this procedure: this protocol was created (and implemented) to solve a particular need for the sharing of ledger (or smart contract) state from one permissioned DLT network to another, and we just extracted a common pattern and found a mechanism to handle it. The use cases draft (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-use-cases/) has examples (see Section 3).
>  
> Rama
>  
> From: sat <sat-bounces@ietf.org> On Behalf Of ladler2@bellatlantic.net
> Sent: 13 January 2023 00:54
> To: sat@ietf.org
> Subject: [EXTERNAL] [Sat] Views
>  
> Hi Rama: I am referring to your two documents linked in your Oct. 17, 2022 email. In the SATP process the only use I can see for a View is to examine the Digital Asset before it is actually transferred. However, it has been stated in the WG
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> ZjQcmQRYFpfptBannerEnd
> Hi Rama:
> 
>   I am referring to your two documents linked in your Oct. 17, 2022 email.
> 
> In the SATP process the only use I can see for a View is to examine the Digital Asset
> 
> before it is actually transferred.  However, it has been stated in the WG meetings that
> 
> the details of the Digital Asset and the transfer must be specified in an agreement that
> 
> precedes the transfer.  So supporting Views is an additional function for the gateways.
> 
>  
> 
> Adding  the processing of Views to the gateways may be useful to support application
> 
> communications between Blockchain networks.  But the additional security problems View
> 
> processing entails is not justified unless View processing is required for SATP.
> 
> We also have a great of work to make SATP a useful protocol in the real world.
> 
>  
> 
> David Millman
> 
>  
> -- 
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat