Introduction

• Agenda bashing - None
• Notes/Minutes will be recorded by Wes
• Rough notes follow below

SATP Architecture

(side note: Wes was busy managing other aspects of the meetings and the
notes are very rough)

• architecture is basically done
• more text was added about the threat analysis

• a future document may be needed about a threat analysis

  • eg, GW2 presenting messages are lost and exhausting GW1

• ownership topic discussed by Anthony Culligan

  • what should be the right vocabulary there -- "own" vs "control"
  • company/buisiness is controlling and legally bound

  • Anthony Culligan (AC): gateways can lock the asset and are
    essentially should be technically verifiable

    • At times you may need a third party
    • A gateway operator may be an entity of some kind
    • the gateway "asserts" statements related to an asset

  • Thomas Hardjono (TH): gateways are a generic way to say "this is
    the endpoint"

    • there will alwyas be a sending and receiving endpoint

  • AC: I think there is a gateway per sender and a gateway per
    receiver

    • a gateway should be a shared resource that is not specific
      to an individual actor
    • there may be many actors in a network, but only a couple
      gateways or two

  • TH: I think the current architecture supports that

    • the gateway's signature mechanisms support the assertions

  • AC: we do this within our software now and would like to be
    compliant with SATP

    • we send a X.509 certificate we can transmit
    • we have to trust the cert authority

  • Venkatraman Ramakrishna (VR): there is nothing preventing us
    from implementing this

    • softening the term to control
    • we cannot avoid having the gatway being in control
    • maybe saying that the gateway has limited control would be
      better

  • Wes Hardaker (WH):

  • AC: mutual TLS should sufficient

    • who would you sue when a particular bank defaulted in the
      middle of a transaction?
    • SMTP operators are not responsible for the content of
      messages being sent, they're really just forwarding messages
    • they're not liable for the content of the message

  • TH: banks may run their own gateway service, or there is a
    contract between the bank and an outsourced provider

    • SMTP may not be the best analogy because this is different
      as there is a fundamental change in state on each side as a
      result

  • Claire F (CF): what does the document say today baout locking

  • TH: the gateway signs an assertion that the asset is "disabled"
    in the origin network

    • proving this is out of scope right now

  • CF: right, at the moment there is a legal relationship between
    the gateways

    • Future work might have a technical way to verify that
      assertions

  • AC: swift transactions are not reliable

  • CF: swift is not quite the right analogy
  • AC: the gateway shouldn't be required to own an object
  • WH: swift is not a perfect analogy because that's really one
    network with many banks participating
  • Martin Hargreaves (MH): I think the analogy that swift is one
    network participating with a gateway makes sense
  • WH: does anyone object to the use of the word "control"?
  • AC: I think it could be made to work and I don't object
  • WH: great, anything else Thomas about the arch document?
  • TH: some points posted to the mailing list today about the usage
    of the word
  • VR: does it make sense to add anything about control/constraints
    of the network?
  • AC: demonstrate control?
  • WH: demonstrate sort of implies proof is possible, how?
  • AC: you can for some types of networks by signatures, etc

IMPORTANT CONCLUSION: "control" seems to be the best middle ground
term for how to reflect that a gateway "has control of" a given asset
during the transfer process.

SATP Core

• 6-7 pull requests to work through
• discussion about proper procedures for deciding when to merge them
  -- after consensus has been reached
• chairs will schedule an interim meeting for June 18th