Session Date/Time: 09 Apr 2024 14:00

SATP

Summary

The SATP Working Group met to discuss the status of its active drafts. Key topics included extending the Working Group Last Call (WGLC) for the architecture document due to concerns regarding its security considerations. Updates were provided on the SATP Core document, including API re-labeling and the strategic decision to move API 1 and API 3 descriptions to an appendix to focus the core document on inter-gateway (API 2) interactions. The group also received updates on the use cases document, network identifiers, and the asset transfer description, which highlighted the role of external registries. Rafael provided a detailed update on two Hyperledger SATP implementations (Hermes and Weaver). Finally, an administrative update announced a change in the responsible Area Director for the working group.

Key Discussion Points

Logistics and Working Group Last Call (WGLC) for Architecture Document
- The WGLC for the architecture document, initially opened four weeks prior, was extended for another two weeks due to limited responses. Participants were encouraged to review the document and explicitly state their support for its publication, even if they have no comments.
- Security Considerations:
  - David expressed discomfort with the current security considerations in the architecture document, emphasizing a need for more explicit threats and mitigations, particularly concerning gateway interactions.
  - Thomas agreed, distinguishing between the architecture document (which should enumerate weak points) and the protocol document (SATP Core), which requires detailed threat modeling for issues like two-phase commit disruptions and specific mitigations (e.g., signatures over claims/receipts).
  - The chairs acknowledged the feedback, indicating the architecture document would likely not proceed to ASG publication until security considerations are further addressed.
SATP Core Document Update (Thomas)
- API Re-labeling: API types 1, 2, and 3 were renamed to API 1, API 2, and API 3, respectively, to avoid confusion with network identifier "address type" terminology.
- Focus on API 2: The discussion of API 1 (client to gateway) and API 3 (gateway to off-net resource) was moved to an appendix in the SATP Core draft. This allows the core document to focus on the inter-gateway API 2. There was a consensus that API 1 and API 3 would require future standardization efforts, potentially in separate drafts.
- Diagram Discussion: A discussion arose regarding the client's placement in the network diagram. While the current diagram depicts clients external to the asset network, it was noted that clients could also be considered internal or have various interaction models (e.g., local transactions detected by gateways). It was decided to take this discussion to the mailing list, potentially suggesting diagram alternatives.
- Key Pair Definitions: Clarified gateway key pairs: a mandatory pair for signing claims/receipts (for legal/financial obligations), an optional pair for secure channel establishment (e.g., TLS), an optional pair for hardware device identity, and an optional mechanism to fetch the business owner's certificate (e.g., x.509 with LEI).
- Flow Diagram Update: The dotted red line for Stage 2 in the flow diagram was adjusted to formally include "transfer commence" and "at commit" as part of Stage 2.
Use Cases Document Update (Rama)
- Three new use cases were added: excising stock options (a complex derivative trading scenario), pay-as-you-go for streaming services (interoperation between content and payment networks), and secure DNS record updates (augmenting EPP for DLT-based DNS records with coordinated updates).
- The use case document's role is to motivate SATP's applicability without solving the problems in detail.
- The document can proceed to WGLC before architecture and core, but will reference the architecture document and may be held for final publication until references are handled.
Identifier Design Team Update (Thomas)
- The design team has largely settled on the core structure for network identifiers, with the design explained via an email to the mailing list. This needs to be incorporated into the draft.
- An open question remains for Type 3 addresses (monolithic systems like RTGS/BIC numbers) regarding appropriate preamble/postamble to fit the 32-byte requirement.
- Type 1 and Type 2 addresses are considered clear. The plan is to update the draft and then open for further WG discussion.
Asset Transfer Description (Dennis)
- Discussion focused on the role of external "Registries" (accessed via API 3) for gateways to verify asset definitions, party identities, and keys.
- Registries would store "asset profiles" (digitally signed documents describing asset schemas) and issuer authorizations, crucial for Stage 0 negotiations and ensuring compliance within specific jurisdictions (e.g., Gateway 2 checking if an asset is acceptable in Network 2).
- The document details the overall structure of asset profiles and their storage in registries, emphasizing the need for third-party verifiability.
- There was a discussion regarding whether these registries should conform to DID registries (e.g., W3C specs). It was concluded that the registry's scope is broader, storing various artifacts (e.g., network identifiers, asset schemas) not strictly limited to DIDs.
Implementations Update (Rafael)
- Hyperledger has two proof-of-concept SATP implementations: Hermes (TypeScript) and Weaver (Rust), promoting diversity in implementations.
- Hermes architecture: A client application interacts via API 1, which translates requests to Gateway-specific requests. The Gateway Orchestration Layer then communicates with other gateways via API 2. An Adapter Layer handles API 3 interactions with off-net resources.
- API 1, while out of scope for the core draft, was defined for implementation purposes, including transactional (transact, cancel, get routes) and administrative (status, health check) endpoints.
- Supported ledgers include Fabric, Besu, EVM-based chains, with plans for Epicsy.
- Roadmap includes an end-to-end working POC by June, crash recovery, audit/compliance tools (leveraging Stage 0 data), and an SATP SDK (API 1).
- Development is open source, with versioning flags included to specify the draft version being implemented.
- While there is some overlap, the Hermes and Weaver teams operate largely independently.
Area Director Transition (Paul Wouters)
- Paul Wouters announced that the SATP Working Group would transition from the Security Area to the Applications and Real-Time (ART) Area. Orie Steele will become the new responsible Area Director, with Paul remaining as a technical advisor. This change is for administrative alignment and does not reflect on the working group's progress.

Decisions and Action Items

Decision: The Working Group Last Call (WGLC) for the architecture document (draft-ietf-satp-architecture) is extended by two weeks.
Action Item: Working Group participants are strongly encouraged to review draft-ietf-satp-architecture and provide explicit feedback, including statements of support for publication, on the mailing list.
Decision: draft-ietf-satp-core will continue to focus on API 2 (inter-gateway interaction), with API 1 and API 3 descriptions moved to an appendix for future consideration in separate documents.
Action Item: Discussion on the client-to-network diagram in draft-ietf-satp-core and the future of API 1/API 3 standardization should continue on the mailing list.
Action Item: Rama and Dennis will collaborate on a draft for Stage 0 / API 1 related issues.
Action Item: Thomas and Wayer will update the network identifier draft (draft-ietf-satp-net-id) to incorporate the design team's current work and bring it back to the working group for further iteration.
Action Item: Dennis and Thomas will complement the asset transfer description document with details on how gateways interact with registries (API 3).
Action Item: Rama will update the use cases document (draft-ietf-satp-use-cases) with the newly discussed scenarios and send a notification to the mailing list, requesting comments on the compelling nature of these use cases.

Next Steps

Continue WGLC for Architecture Document: Address security considerations identified.
Iterate on SATP Core: Refine document based on API re-labeling and diagram discussion outcomes.
Develop API 1/API 3 Drafts: Initiate work on separate documents for API 1 and API 3 as future work items.
Update Identifier Draft: Finalize identifier design for review.
Refine Asset Transfer Description: Detail Gateway-Registry interactions.
Review Use Cases: Gather feedback on newly added use cases.
Continue Implementations: Progress on Hyperledger Hermes and Weaver, including planned features.
AD Transition: Chairs to work with Paul Wouters and Orie Steele for a smooth transition.
Schedule Next Meeting: Chairs will work to schedule another interim meeting in approximately one month.