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: Mon Oct 19 13:48:49 2026

*Summary*

As far as I can tell as a non-specialist, the ... is in good shape.
There are ... below.

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_.

*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.

  I've listed all this as 'minor' only because it is a matter of
  terminology, but I think it's important to fix it.

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


*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'

15.1

 RFC 8446 is obsolete, should refer to 9846.