Minutes IETF125: satp: Thu 01:00
minutes-125-satp-202603190100-00

Meeting Minutes Secure Asset Transfer Protocol (satp) WG
Date and time 2026-03-19 01:00
Title Minutes IETF125: satp: Thu 01:00
State Active
Other versions markdown
Last updated 2026-03-24

minutes-125-satp-202603190100-00

IETF Secure Asset Transfer Protocol (satp) WG

Date: Thursday -- 2026-03-19
Time: 09:00 - 11:00 Local
Room: Hebei

AGENDA:

  • 5m - Chair Introduction (Wes Hardaker and Claire Facer)

Since last IETF, Orie as AD provided AD review and requested revisions,
following which the authors updated the three core documents. After
that, Andy will give another round of AD review as incoming AD, after
which they will be sent to IESG review.

Current Work Items

Handling AD comments about submitted drafts - Thomas Hardjono

  • Changes to draft-ietf-satp-architecture:

    • The authors made updates based on feedback from Orie:
      • Mandate consistent use of TLS 1.3 and remove references to
        TLS 1.2 to ensure high security for financial use cases.
      • Changed from 3-phase commits to only 2-phase commits.
      • Suggest reading order: Architecture first, then Core.
      • Editorial improvements, standardization of the
        terms(should/must/may->SHOULD/MUST/MAY), aligned with other
        documents.

  • Changes to draft-ietf-satp-core:

    • Above changes to the Architecture also apply to the Core.

    • Apart from that:

      • Fixed broken citations and misaligned terminologies.

    • Public key format problem: Orie: Public key format
      conversion could often go wrong. The authors should reference to
      the public key format that is used in this document.

      • Thomas: Use JSON-related constructs like JWK. Do
        serialization/canonicalization before using.
      • Orie: Recommend use JSON Canonicalization Scheme (JCS) or do
        base64 encoding (Denis confirms their use of JCS in the
        chat). Look at how JOSE handles protected headers.
      • Wes: Need to define the structure for interoperability, pick
        one or cite an exact RFC. Need to be addressed. Check all
        references as needed.
      • Andy: Referencing JCS might result in a "downref" during
        IESG review.

    • Error code problem: Error codes for malformed identifier,
      error code also helps retransmission

      • Orie: Could reuse HTTP problem detail format or other widely
        used methods.
      • Wes: As operator, error codes with rich detail is helpful
        context.
      • Andy: Align with BCP 56.

  • Considerations to draft-ietf-satp-usecases:

    • Andy: there are some existing company names that needs be
      removed (verisign, godaddy...). We cannot reference common
      names. For DNS names need to change to example.com or .example.
    • Orie: REGEXT wg also have EPP-related use cases. Orie
      recommended coordination with these working groups.
    • Orie: SCITT & SPICE are doing bill of lading definitions etc…
      they are sometimes talking about what SATP might call “Asset
      Schemas”. Could reach out to those people.

Recharter Text - Chairs

  • Recharter text was produced as a result of discussion acorss
    previous 2-3 IETFs, Claire helped polishing, just proposed to the
    mailing list.
    • Thomas, Alexandru, Rama, Denis, David is happy with the new
      charter.
    • Andy: Should wait the first batch of three documents enters the
      queue and pass ballot before rechartering.
    • Wes: Timing of recharting text being sending to IESG review is
      up to AD.

Near-term Work Items

Stage-0 Architecture and Protocol - Thomas Hardjono

Stage-0 is a setup phase prior to SATP transfer. Three problems will be
focused to address:

  • Pre-Transfer Context Establishment
  • Asset issuers “publish” artifacts metadata about the asset to an
    Artifacts Registry(s)
  • Discovery and access to asset-related artifacts

Need an Artifact Registry module: A registry for off-chain metadata
(legal documents, profiles). Requirements include append-only logging
and "50-year persistence" to meet financial regulatory standards.

  • Orie: Suggest utilizing the DNS for discovery and naming rather than
    building a new specialized registry system.
  • Thomas: While DNS is good for discovery, the persistence
    requirements (50year+) of financial assets might require a system
    more like a distributed ledger or those discussed in the SCITT.
  • Denis: Need persistency system outside of the protocol, need
    liveness property for notifications, need asset profile discovery...
    pubsub is orthogonal to registries.
  • Thomas: We could reuse Authenticated Transfer (ATP) if necessary.

AOB

  • Orie: Schema registry is used/appeared in many places, if this
    schema be defined crystalized, coordinate with other working groups
    would be useful.
  • Denis: Presented SATP Artefacts and Registry Component, explained
    how Tokenized Artefacts Record (TAR) and Digitized Artefacts Record
    (DAR) works. Explains requirements like consistency across
    jurisdictions.

Current WG documents:

Other documents