Note taker: Orie Steele
Chairs: Notewell and working group introduction
Chairs: We have been requested to do a review of our WG milestone and
their proposed dates?
Architecture and core documents 6 months out?
Use Cases 1 year or more?
Rama: Use cases cover initial scenarios for the architecture.
Use cases seem to be in good.
Chairs: How much time do we need to cover use cases.
Rama: Document is ready for WG review.
Chairs: We'll update the milestones, and target the documents for
delivery to the IESG at these new approximate above times.
Some discussion in the room on document stages, and IETF wide review
after workin group finishes, see:
https://chairs.ietf.org/documents/lifecycle
Thomas: We've seperated identity layer activities from the protocol and
moved them to stage 0, from stage 1.
Presentation about architecture diagram updates.
Previously the application could talk directly to the asset network.
Today, the applications can speak to the asset network and the gateway.
We are exploring the possiblity of gateways providing views on the
assets and state of the assets to applications.
We are discussing API-2 which is gateway to gateway.
API-1 is the direct connection between the application and the gateway.
Paul: It seems risky to discuss APIs which we are not allowed to
specify.
Wes: Some history of the group... there is interest beyond the initial
charter... The core protocol is really about API-2 and the other APIs
are currently out of scope for the charter.
We are documenting some of these imposed requirements based on the
larger archeticture, without describing concrete solutions and details.
Thomas: The ContextID is documented in the core spec. Though remains out
of scope for this charter. We are specifying that the existance of
contexts is mandatory now, where previously we had this as optional,
though how it is computed is out of scope.
Wes: There is a need to identify a context via the contextID. This is
needed so that more complex future situtations can be considered, such
as when one transfer fails and another succeeds. Today we do not not
have a way to bind them together, and our charter restricts us from
specicifying binding mechanisms at this time but architecturally we
understand there is a requirement for its existance.
Orie: Be careful describing work that is out of scope and out of
charter, at the working groups and in your documents.
Liang: I want to understand the security of the asset protocol, what are
the security properties.
... this seems app layer protocol, no network layer?
Thomas: We assume TLS between gateways, and the security focus is on
2...3 phase commit protocol, to provide consistency in transfer.
Wes: For requirements... what remains before this document is ready for
the IESG? Have you addressed feedback from directorate and list
contributirs.
Thomas: We need to expand on a few things, but do not expect any major
changes.
Thomas: There are many aspects of stage-0 (agreement about what a
transfer should consist of, who the parties are, etc) which are out of
scope.
... this problem is beyond IETF and is international finance and
governance policy related.
We are trying to define a schema to capture metadata information.
Banks could be gateways operators, and each have their own metadata and
indentifiers that need to be considered.
API-2 is the gateway to gateway API.
Exact definitions of the other APIs are out of scope today.
As ledgers have evolved, network forks have lead to inconsistent network
identifiers.
The EEA, has defined network addresses as originating from the genesis
block... We have the general problem of needing to identify the network
on which the asset resides, regardless of the network type.
What about identifiers for private networks?
SATP has always assumed that private networks are possible on both sides
of gateways.
Does the transfer context ID include the networks?
Paul H: I am assuming the WG intends to move core and architecture
together at the same time...
... It does not seem possible to move them forward independently.
Wes: great question, we have not considered binding them... I was going
to ask what is left.
Paul: I can't imagine reviewing these documents in isolation.
... ideally these might have been 1 document, reviewers will struggle
without reading both.
Thomas: There are normative references from CORE to the architecture.
Paul: There appear to be normative assumptions that need to be
considered... please consider not sending the documents forward at
different times. For anything that is called out in one document and not
the other, please consider calling out the assumptions in both
documents.
Thomas: We will clarify the assumptions on document dependendicies.
Wes: suggests stating that architecture doc should be read before the
Core document as well as making these ammends.
Rama: CORE is meant to provide a specific type of interoperability, not
general and broader scope as disucussed in the architecture.
Architecture does have a larger scope.
Thomas: today there is a 1 way dependency... we think the real work is
now in core... but will make a norative reference in Core that calls out
that Architecture should be read first to be able to understand Core.
Wes: what remains to complete the document?
Thomas: The document is basically complete after some final edits.
Wes: call for show of hands - Who has read architecture document fully
at least once recently? Yes 10, No 8
Wes: Call for show of hands - Who has read the core document recently?
Yes 9, No 10
Wes: there are at least a couple implementations already, correct?
Thomas: In terms of implementations, there are at least 2 open source
and 1 closed source.
Wes: If you implemented, and you had to guess at any aspects of the core
protocol... you need to provide that feedback to the list ASAP.
Claire: I'll follow up with implementer experience (from an intern at
Quant implementing a version) on the list.
Rama: These operations cover business workflows to exchanging and
transfering assets.
Wes: An example of this in the early use cases we discussed, was the
bill of ladding, right?... it was declared out of scope for now but is
still a valid use case.
Rama: Bill of ladding can be done via data sharing which is out of
scope, but it can also be considered a digital asset.
... We added new use cases.
... use cases are both trade and supply chain oriented as well as
decentralized finance and central bank backed digital currencies.
There is a new discussion of how SATP might be used in the EPP protocol
from REGEXT.
EPP occurs at Stage 0 which is currently out of scope.
Anthony: I'm involved in traditinal finance, and we rarely use DLT or
blockchain... This protocol seems to not be limited to blockchain or
DLT... but the use cases appear to be focused on blockchain... but it
seems that there are more use cases that do not require blockchain which
the protocol could support.
My advice is: within the use cases document, get more use cases that do
not focus on DLT / blockchain, but that speak to the common cases in
finance, I see demand for this kind of protocol, and look forward to
contributing.
Wes: We've always been ledger agnostic, and we welcome your
contributions and text.
Anthony: Cloud based ledgers, are innovating, and not movng from
traditional to DLT... but from on prem to cloud... this is an
opportunity for SATP, and be part of that integrating layer. I can
contribute text to help here.
Liang: Based on use cases, are there any security challenges or gaps for
existing protocols?
... or generally speaking, we can use existing protocols to solve
security issues... I want to know what security means in this context.
Rama: the security part is mostly focused on the integrity of the
transfer... we need to avoid "double spend", or "accidental
destruction"... we're building on existing security technologies to
provide these properties.
Thomas: We discussed a threat model... its less about comsec, and more
about gateway and network security and consistency properties... what
happens when faults occur in the protocol, can they be recovered from?
... we've been asked about threat modeling, and there is some text at
the end of core regarding threats.
... We focus on satifying the 4 assert properties and ensuring gateways
cannot cheat.
Liang: Thanks
Peter: I proposed some use cases... I wanted to explain some more about
the asset watch use cases.
... today in china, they are building overlay networks to support
assertization of data and chunks... and they are trying to align asset
transfer with data transmission.
... the point of that use case is that the data transmission and asset
transfer can happen at the same time.
Rama: Can you share any links to what you said on the mailing list.
Peter: They will be in Chinese, but I will [ED: and did] share.
Wes: What is next for these documents.
Rama: There was some discussion on the list, we have some comments to
respond to... mostly questions.
... We may add additional use cases.
Orie: focus your document on clear, distinct and succinct use cases
Wes: yes, agreed, we need examples of different types of use cases, not
every possibile combination
Denis: We're looking at the diagram in the draft...
https://datatracker.ietf.org/doc/draft-avrilionis-satp-setup-stage/
David: Step 4, how is that message transfered from app1 and app2.
Denis: It assumes that there is a channel for app to app communication.
David: Ok, so we will leave it undefined?
Denis: It can be any app to app flow, but its outside the scope of stage
0.
Wes: Our charter limites us to specific work.
Anthony: I think this context is important, and we can see that there
are transaction dependencies that need to be considered... I think that
context will be essential to linking SATP components together.
... typically the parties will become aware of these transactions out of
band.
... parties agree out of band, and then communicate to the applications
directly.
Denis: beside the semantics of what is transfered, there are technical
challenges... if we have asset locking... we need to consider
concurrency and its impact on transfer contexts, and this can help
managing concurrency... transfer context could be helpful.
Ned Smith: Can you give intuition on binding assets to a network?
Denis: There is a state where assets are reserved for a transfer... if
the network knows about a transfer context.. it can be aware of this
state, and the lifecycle of the asset inside the network... If there is
a DLT behind the gateway, we may need to burn or mint the asset...
behind the transfer context, there may be lifecycle activity.
Thomas: When you have a group of assets, we need to prevent the network
for touching assets that are in the process of being considered for
transfer... we have previously used the term lock...
Ned: The term network is throwing me off a bit...
Wes: We are calling this an "asset network"... we need to be careful to
consistently use that terminology. It is clear from multiple discussions
today that people are confusing "IP networks" and "asset networks".