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 |
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
- Thomas: yes there isn't -- we could add one, but it's a
-
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?
- Thomas: in theory yes, but it opens to a lot more
-
-
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
- Thomas: the core document I hope to have done by the end of the
-
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
- Thomas: good question. We need to figure that out. Maybe
-
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
- Thomas: right now we're looking at the simplist case where
-
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)
- Thomas: the client may be wanting to do two related
-
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
- Wes: we have 2 hours in madrid and can have another interim
-