Skip to main content

Minutes interim-2025-satp-01: Tue 14:00
minutes-interim-2025-satp-01-202506171400-00

Meeting Minutes Secure Asset Transfer Protocol (satp) WG
Date and time 2025-06-17 14:00
Title Minutes interim-2025-satp-01: Tue 14:00
State Active
Other versions markdown
Last updated 2025-06-18

minutes-interim-2025-satp-01-202506171400-00

IETF Secure Asset Transfer Protocol (satp) WG
Date: Tuesday -- 2025-06-17 -- 14:00 UTC
Room: Meetecho

AGENDA:
5m - Chair Introduction (Wes Hardaker and Claire Facer)
Note takers needed
IETF process reminders
20m - Updates to the SATP-core document (Thomas Hardjono)
5m - Updates to the SATP-arch document (Thomas Hardjono)
5m - Discussion with the chairs about submission readiness
30m - Report on Stage-0 and API discussions (Thomas Hardjono)

Updates to the SATP-core document (Thomas Hardjono)

  • Error messages were updated heavily

    • error-codes now match flow numbers
    • defined an error message type which is different than the abort
      menu
    • includes a hash of the previous message

      • wes: why not a message ID?
      • thomas: could be done that way
    • severity now included but not well defined

      • wes: subjective
  • session-abort message type is a separate entity

    • can abort anytime before commit-final (3.5)

      • Denis: the abort should be up until 3.4, not 3.5

        • Thomas: generally agrees he thinks but will look
      • Rama: can either side abort?

        • Thomas: yes
      • Rama: right now there is no reason code or anything?

        • Thomas: yes there isn't -- we could add one, but it's a
          subjective list
      • Rama: can we have a suspend for a time message?

        • Thomas: in theory yes, but it opens to a lot more
          attacks
        • Rama: one reason is that the gateway behind is taking a
          lot of time to record the transaction
        • Thomas: it might be better to cancel the transaction
          instead and try again in a few minutes?
    • note: some of these changes may only be in the github version
      right now, not the published version

  • security considerations

    • arch doc has longer security considerations

Updates to the SATP-arch document (Thomas Hardjono)

  • was updated and

Discussion with the chairs about submission readiness

  • Peter: sheparad write ups started about arch which should be done

    • Thomas: yes, that should be done
  • Peter: what about core?

    • Thomas: the core document I hope to have done by the end of the
      month
  • Rama: use cases draft will get an update shortly as well

Report on Stage-0 and API discussions (Thomas Hardjono)

  • overview of the problem: organizations need to decide early on how
    to negotiate the expected contents of a SATP transfer
  • diagram overview of stage-0 shown

    • application / gateway / network
  • assumptions:

    • applications know about the gateway and network
    • gateway knows about the network
    • network only knows about intention
    • applications help establish the connection between the gateway
      and the network
  • flow diagram shown about how to negotiate

    • Rama: is step 2 (a read) a push or a pull?

      • Thomas: good question. We need to figure that out. Maybe
        both even?
      • Rama: we can specify the format now at least
    • Peter: general question -- there is an intent of transfer now.
      Some existing customers of deployments want to even know how the
      asset will be used?

      • Thomas: right now we're looking at the simplist case where
        the asset needs to be moved. There is a bigger context
        around this with respect to bi-directional transfers too.
      • Peter: the transfer of the dataset along with the asset to
        indicate
    • Wes: watch out for extensions needed later and being able to add
      new features in the future as right now the core document is
      limited to a single direction transfer, not bi-direction so at
      some point we may need to update the core document to handle
      future things and versioning now needs to be thought about.

      • Thomas: yes we're trying to handle that
    • Denis: re: Extensions. We only have unidirectional transfer at
      the moment, and with only two gateways at the moment.

      • We may need multiple-gateway scenerios in the future
    • Denis: If there are several gateways and need to implement
      locking, we need an intention negotiated in the beginning

    • Denis: We need to spend time optimizing the flows

      • Thomas: the client may be wanting to do two related
        transfers
      • Thomas: is there a need for a cordinating gateway? (which
        SATP is geared for due to it's three-phase commit)
    • Peter: Definitely need space for future extensibility

      • Thomas: we all agree here about that!
    • Thomas: we need more participation in these discussions

      • Wes: we have 2 hours in madrid and can have another interim
        in August if need be