SATP Meeting IETF 121

• Chair introduction

Architecture update

• updated diagram
• received comments from John
• may need an update only if core changes some

Core document

• updates to core-05 discussed
• discussion around the need to include the identifier previously
  agreed to in the opening of the stage-1 message. This allows the
  receiver to verify that the credentials match what was previously
  received

question about whether we should have a general purpose reject message instead of just an initial one

• what is the procedure when a reject is taken though? (Rama asked on
  the mailing list)

• options:

  • 1. please resend because I'm not happy
  • 1. reject and abort

• thus the reject message can be the conveyer of a message

• question Wes: is this a generic error message then that will be
  reused other places?

  • most likely -- there are some other places where this might be
    used

• Denis: multi-phase commit protocols are designed to fail and thus
  this should be part of a normal processing

  • 3.5 is the message that can kill the whole thing
  • must deal with the case where no message may be received

• Denis: the non reception of 3.5 may stall the whole transaction

  • this is in the threatts section at the end of the document

Use case document

• document describes use cases between two different networks
• transfer, query between the two, of data sharing / transfer
• showcase scenarios and challenges in the industry

• 4 main sections of different types of scenarios where SATP can be
  used

  • international trade and supply chains
  • decentralized finance and CBDC
  • Decentralized commerce
  • Augmenting Trust in internet Protocols

• we need new cases that document brand new scenarios that are
  different than the existing ones, rather than more examples of the
  same types of cases.

• Question: can SATP be used for digital representations to
  manufactured supply chains, parts and things are moved between
  suppliers with accountability

  • two organizations that are handing over goods legally
  • Denis has a draft on asset schemas that this could fit into
  • goal would be company to company and relationships can change,
    or could even be different units within a company

• Peter: will volunteer for reviews

• Peter: there is ongoing work in Asia with underlying transfer of
  technology that is becoming popular to moving things around. I think
  this will be similar to what is in Section 5, but need to check.

Case study: South Karea CBDC pilot project

• central bank project
• https://cbdctracker.org/ shows the status of the central banks
• requirements for cross-border payments
• might use SATP for payment services for transferring assets, and
  HTLC for asset exchange
• used hyperledger cacti SATP connector
• unctionality worked well in the demo environment

• difficult to evaluate the implementation

  • integrated into the existing environment
  • checked that it worked well in the scenario
  • how can we evaluate that SATP is safe?
  • is it the right solution for cross-boarder payments, as there
    are other types of payment solutions.

• report will be published next year

• will look at current status/issues of the group
• wondering what the next steps are for the SATP WG and how we can
  integrate more
• question: have you interacted with the cacti maintainers and discord
  channel?
  • not yet
  • some external help, but not much yet

Overview of the IETF process

• will need document shepards
• will start a 4-week last call of all 3 documents

next steps for SATP

• over all goal: architecture of networks with gateways

• Rama: needs for asset transfer is one part of a larger workflow

  • discovery of other networks
  • properties of current state in another protocol
  • how do you query a protocol that does not expose its entire log?
  • proof of authenticity to enable trust
  • cross-network query and response

• ledge state views and addressing

  • add views and addresses
  • data sharing protocol/querying
  • basically need a way to request a view sub-segment of another
    blockchain through a request to the gateway

• essentially two documents:

  • view address definition document
  • and a request/response protocol

• Denis: want to start with the stage-0 draft

• also the asset profiles
• API-3 could use a definition

• question: should the api-3 go into the profiles draft, or should it
  be separate

  • they are somewhat orthagonal

• Claire: we should also look at exchanges

• Orie: best to concentrate on one case that be completely deployed
  and makes sure that there are no holes

• Denis: we are implementing and deploying and we really need the
  profiles and stage-0 stuff solved to get that out the door