Re: [Sat] Version -02 of the SATP core protocol draft ---- FW: New Version Notification for draft-hargreaves-sat-core-02.txt

Hi Thomas,

I proposed to present a message flow to cover the transfer context for our meeting 14 March. 
@claire @wes please tell me if I can have 10’ to present on Tuesday.

To my view the transaction context includes the session id so perhaps we can refer to a transaction context ID throughout the flow, that would be simpler than the couple <contextID, sessionID>

--
Denis

> On 12 Mar 2023, at 00:46, Thomas Hardjono <hardjono@mit.edu> wrote:
> 
> 
> 
> Folks,
> 
> Attached below is the link to an update the core protocol draft.
> 
> 
> (a) The major updates to the draft :
> 
> -- Uses the terms "Lock Assertion" and "Receipt" (instead of "Evidence").
> 
> -- Inclusion of an explicit "session_id" value in each message.
> 
> -- The addition of a new subsection on the Commit-Ready message (which previously was not in draft-01)
> 
> -- The message flows now matches our agreed flows in v16 of the color message-flow diagram PNG file (in our repo).
> 
> 
> 
> (b) What was not added as yet (but text may be needed):
> 
> The architecture draft-03 talks about a Context-ID, which is transfer-context information/parameter that App1 and App2 are assumed to have established in Stage 0 (which is out of scope for SATP). This occurs at the Application level/layer, before SATP gets kickstarted.
> 
> The idea is that the Context-ID value could be (should be) bound somehow to the session_id so that the Applications can always see the progress of a transfer occurring between the two gateways.
> 
> Because the App1 & App2 could have multiple independent transfers occurring simultaneously and some of those may be handled by the same pair of gateways G1 and G2, the combination of the <Context-ID, session_id> allows each transfer flow to be identifiable.
> 
> We need to discuss this more, I think.
> 
> 
> 
> Best
> 
> --thomas
> 
> 
> ________________________________________
> From: internet-drafts@ietf.org [internet-drafts@ietf.org]
> Sent: Saturday, March 11, 2023 5:29 PM
> To: Martin Hargreaves; Rafael Belchior; Thomas Hardjono
> Subject: New Version Notification for draft-hargreaves-sat-core-02.txt
> 
> A new version of I-D, draft-hargreaves-sat-core-02.txt
> has been successfully submitted by Thomas Hardjono and posted to the
> IETF repository.
> 
> Name:           draft-hargreaves-sat-core
> Revision:       02
> Title:          Secure Asset Transfer Protocol (SATP)
> Document date:  2023-03-11
> Group:          Individual Submission
> Pages:          29
> URL:            https://www.ietf.org/archive/id/draft-hargreaves-sat-core-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hargreaves-sat-core/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hargreaves-sat-core
> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-hargreaves-sat-core-02
> 
> Abstract:
>   This memo This memo describes the Secure Asset Transfer (SAT)
>   Protocol for digital assets.  SAT is a protocol operating between two
>   gateways that conducts the transfer of a digital asset from one
>   gateway to another.  The protocol establishes a secure channel
>   between the endpoints and implements a 2-phase commit to ensure the
>   properties of transfer atomicity, consistency, isolation and
>   durability.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> -- 
> sat mailing list
> sat@ietf.org
> https://www.ietf.org/mailman/listinfo/sat