Chair Introduction (Wes Hardaker and Claire Facer)

• Note takers needed: Wes will take notes and others can help

Updates on the SATP-Core draft (Thomas Hardjono)

• the only major outstanding thing was the security considerations
  section
• focus has been on the gateway/operators
• some expired drafts on networking identification, etc, which will
  need to be handled after this is published

Asset management model for Stage-Zero

• One early identified need is a terminology set for how to discuss
  gateways doing locks, etc, and what a lock really means.
• There are multiple future scopes where interactions need to occur
  between an app, a gateway, and a network
• There needs to be a model for the common layers, to clarify layer
  boundary, avoid invasion, etc.
• Flow diagrams between client app/network/gateway needs further
  thinking

• Wes: what portions of slide 3 need interoperability

  • Definitely c, and it needs locking definitions

• Wes: for things like locking, is there a need for a common API or
  just a definition of what a "lock" is?

  • You need to specify particular types of locking mechanisms and
    what they really mean in an implementation layer

• Denis: (b) needs a data structure, so the semantics are needed not
  necessarily how they flow

• Thomas: the lines really means a mechanism for communication

• Peter: for a and b, is there any current reference implementation
  that exists already

  • Thomas: there aren't references but there are implementations,
    especially with wallets
  • Transfer context needs to be defined minimally
  • Need to define and agreen on an assetid
  • Peter: can we have some examples of what that will look like?
    Such that we can extract the minimum common set.
  • Thomas: agreed, we need sufficient examples in order to do that.
    We will do such analysis when we are actually doing this work
    after recharter.

• Rama: There are reference implementations within cacti already for
  all of a, b and c

  • CBDCs have use cases
  • There are some older presentations about use cases as well

• Denis: there is a draft on the transfer context

• Wes: which of a/b/c are likley to be an API vs a REST like network
  protocol?

  • b is likely to be a REST protocol
  • c is likely going to be an agreed upon data structure to pass
    around
  • a will likely be a data structure
  • We will need to define a minimal fields

• Denis: the original intent of this group is to define the transfer
  protocol. After a number of years we know there are a bunch of
  additional things we now need realize we need in a bigger context.
  We likely need additional components like registries to store these
  additional attributes.

• Wes: will there be another gateway inside the network

  • Thomas: There could be yes

• Wes: is it possible that it could be done by having the app talk
  through b to the gateway to c?

  • Yes, we have been talking about that too.

• Claire: could there be proof of availability, etc?

  • Yes, and one thing to do is to make the ID be able to be
    properly used as a unique identifier
  • Believe 32 bytes may be insufficient?

• Claire: we can't put to many constraints that will prevent
  implementation

  • ISO222 is the standard that banks use.

• Peter: about the asset id, we haven't finalized the spec yet right?

  • There is a starting draft that we need to republish

• Peter: there are many designs for UUIDs/DIDs or similar now that we
  should consider looking at

  • Yes, we need to

• Wes: I will warn you again that a fixed length identifier as short
  as 32 bytes will be insufficient and/or inflexible and we need to be
  more future proof.

Next steps for the SATP WG

• Goal for right now: poll for who thinks some of the brain stormed
  items from last time are what we should concentrate on next.

  1. Stage-0

     1. (part of 1) Asset ID
     2. (part of 1) Network identification and encoding those
        identifiers (started in a draft already)
     3. (part of 1) Transfer context establishment

  2. Bill of lading

  3. Bidirectional transfers and exchanges
  4. Data Sharing - address information from another network, views
  5. Metadata
  6. A registry / API-3 for negotiating requirements for the protocol
     to run
  7. Requirements of each implementation (locking, rollback, …) – a
     minimum list of requirements that SATP requires on the gateway
     and/or network?
  8. Implementation guide for gateways
  9. Threat model
  10. Terminology document
  11. Network and gateway and location discovery

• Denis: use case and other things can be eliminated

  • 1, 9, 10

• Thomas: 1, 9, and 7

• CLaire speaking on behalf of luke: 6 (exchanges)

• David: 1, 12, 10

  • We really need a threat model

• Peter: 1, 7, 12

  • We need a threat model and an operational security considreation
    draft
  • Data sharing can attract a lot of good
    momentum/experience/practice from ongoing data sharing projects
    in EU and CN

• Rama: 1, 7, 14

  • The drafts for 7 are inspired by real world use cases

• Claire channeling a chat message: 1, 9, 11

AOB

• Wes mentioned that if someone could review the use case document and
  analyze what subsequent work items each use case would require, it
  will be great and will be helpful for recharter.
• Peter to send the shepherd documents (2) to the chairs again.