IETF Last Call Review of draft-ietf-satp-core-17
review-ietf-satp-core-17-artart-lc-thompson-2026-10-21-00

https://datatracker.ietf.org/doc/draft-ietf-satp-core/
Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html
Title: Secure Asset Transfer Protocol (SATP) Core
Reviewer: Henry S. Thompson
Review Date: Wed Oct 21 17:12:16 2026

*Summary*

This draft is part of a package of at least three parts, including
also _Secure Asset Transfer (SAT) Interoperability Architecture_ and
_Secure Asset Transfer (SAT) Use Cases_.

Its aim is to present a concrete instantiation of the SAT
Interoperability Architecture in terms of a specific set of message
formats.  As far as I can tell as a non-specialist, it achieves that
goal.

But in my opinion it needs work on the presentation, particularly in
the area of consistency and transparency of terminology, both
internally and in relation to the terminology established by the SAT
Interoperability Architecture, which I take to be the senior party in
the trilogy.

All of my comments below under 'Minor points' bar the very first are
there, rather than under a more serious heading, only because this is
a matter of presentation, not substance, but I think it's important
that they be addressed.

*Minor points*

1.

  The restriction to just HTTPS with TLS1.3 is almost certainly not
  what you want.  The use of HTTP/2 or QUIC, which requires use of
  TLS1.3, should be allowed.

  In the Introduction, all that's needed is something along these lines:

     Secure transfer mechanisms such as HTTPS with TLS no less than 1.3
     must be used.

  5.3.9 and 5.4 can actually be simplified by switching to language
  which allows for successor messaging systems which offer the same or
  better security than HTTPS with TLS1.3.

  There might be an argument for a SHOULD support HTTPS with TLS 1.3,
  but only if there is a strong case for encouraging interop between
  different gateway implementations.

5.3

  The use of the word 'client' here and and client/server terminology
  in 5.4 is unnecessarily confusing with respect to the use of
  'client' as defined in section 3 and used in section 4 (the SATP
  model) and 5.3.8.  

  The fact that 'client' is used with two different meanings in the
  section headings of 5.3.8 and 5.3.10 illustrates this unnecessary
  confusion.

  ARCH uses 'client' only in the 'client application' sense, and
  'server' not at all, and it would be a good idea to stick with that.
  Following ARCH, Section 3 defines "sender gateway" and "recipient
  gateway" and I would very much encourage their use throughout, as
  already done in 5.3.2.

  For example, 5.3 para 1 could read

   SATP messages are exchanged between peer gateways, where depending
   on the message type one is the sender gateway and the other the
   recipient gateway.

  and in 5.3.9

   If the sender gateway transmits a list of supported credential
   schemes, the recipient gateway selects one acceptable credential
   scheme from the offered schemes.

  and in 5.3.10

    *5.3.10. Sender Gateway Offers Other Supported TLS Schemes*

    If a sender gateway wishes to use TLS schemes other than the basic
    scheme (AES-128 in GCM mode with SHA-256), then the gateway may
    may choose to send a JSON object listing the client's supported
    TLS schemes.

  Also, later on the terminology used changes from 'recipient gateway'
  to 'receiver gateway' -- this should be reverted throughout.

5.4.1

  See above.  Here's a simpler version of this whole section:

  5.4.1. Protocol requirements

  Gateways MUST use a secure protocol, HTTPS or successors, in this stage.

  Gateways MUST use the HTTPS POST method or equivalent idempotent
  [RFC 9110] method in this stage.

7.

  remove ' (client)' and ' (sender)'

8., 9., 10.

  remove and/or replace 'client', 'server' and 'receiver' so that all
  and only 'sender gateway' and 'recipient gateway' are used.

8.3. and others

  Starting here there are many sentences of the form

   "This message is sent from ... to the ... Endpoint at ... ."   

  The typography implies that these are formal properties of SATP, but
  as far as I can see there is no definition of 'endpoint' or how the
  many different ... Endpoints are to be identified between the two
  gateways.  Is this information meant to be included in the 'transfer
  context' as defined in 5.3.6?

8.4. and others

  8.3. and 8.4. define the *Transfer Proposal Message* and *Transfer
  Proposal Receipt Message*. There are a number of message pairs with
  similar pairs of names, with the second part being variously named
  ... Receipt Message or ... Response Message.

  Language along the lines of "The message is sent from the [recipient
  gateway] to the ... EndPoint at the [sender gateway]" appears in
  many if not all of them

  It's never made clear if this just e.g. requires *Transfer Proposal
  Receipt Message* as the form which the HTTPS response body should
  adopt when responding to an HTTPS POST request in the *Transfer
  Proposal Message* form or, as I read it at first, actually means a
  _separate_ HTTPS POST request in the *Transfer Proposal Receipt
  Message* format is sent from the recipient gateway.

  That is, are we being told about a single HTTPS exchange, or two?
  Or is the intent to allow for either?  I think either at the
  beginning of section 8, or somewhere earlier, perhaps section 6,
  this should be explained.  Indeed Figure 2 in section 6 might
  encourage one to think that the Transfer Proposal exchange requires
  one HTTPS exchange, whereas the Lock Assertion exchange involves
  two.

11.

  The discussion of time-outs and aborts leaves it unclear whether a
  gateway which times out waiting at some point in a session should
  send a session-abort-msg or not, but I would think it should.

  Note that the phrase "time-outs due to gateway crashes" doesn't make
  any sense: from the point-of-view of a gateway (G1) which times out
  waiting for a response, there is no way to detect the _reason_ for
  the timeout.  In case a timeout is _not_ because of a crash on the
  part of the other gateway (G2), surely notification that the session
  is being terminated by G1 should be sent, to enable an orderly
  close-down by G2, instead of it having to time-out itself.

*Nits*

3.

 Since you use them both, I suggest including the ARCH definitions of
'originator' and 'beneficiary' here.

5.3.15
  immobile => immobilize [twice]

  'uses Hashed Time-lock' => 'use Hashed Time-lock'

8.1., 8.2., 8.6., 9.1, 10., 11.3., 11.4.

  must => MUST [throughout]

8.4., 8.6. and 9 others

  The example JSON ends with a comma, which is strictly speaking not
  allowed, and may cause errors in some tools (e.g. jq).  It would be
  best to remove them.

11.3.

  The example JSON is missing a comma after
  "urn:ietf:params:satp:core:msgtype:transfer-proposal-msg"

11.3.

  errror => error

11.4.

  I think *Protocol Error Codes* would be better...

11.5.

  'maybe' => 'may be'

12.

  'such a' => 'such as'

15.1

 RFC 8446 is obsolete, should refer to 9846.