Session Date/Time: 16 May 2023 14:00

SATP

Summary

The SATP working group met to discuss the status of adopted documents, particularly focusing on author updates for error messages and Gateway identity. Key discussions included the long-term publication strategy for the vocabulary/glossary, the relevance and potential reuse of ISO 20022 standards, and a proposal for multi-stage protocol endpoints. The working group also acknowledged and discussed early review comments from the HTTP Protocol Directorate. Future work includes a dedicated interim meeting for error message handling and further investigation into ISO 20022.

Key Discussion Points

Agenda Review: The proposed agenda (author updates, ISO standards impact, other items) was adopted without objection.
Vocabulary/Glossary:
- The vocabulary is currently in a GitHub repository as part of the material.
- Discussion on long-term publication options:
  1. Leave in GitHub (least preferred by some).
  2. Publish as a separate Internet-Draft (might require minor charter adjustment but seen as feasible).
  3. Include as a section within the architecture document.
- A preference for formal publication as a separate document or within the architecture draft was noted for consistent reference.
Author Updates (Thomas):
- SATP Core (Error Messages): Work is in progress with Raphael and Martin to collect and categorize error messages, drawing inspiration from the TLS error model. The approach involves identifying potential failure points in each protocol stage (1, 2, 3) from an IT engineer's perspective.
- Gateway Identity Identification: Discussions with Shipping and Dennis are ongoing in a bi-weekly subgroup. Key aspects include:
  - Models for identification and discovery (hierarchical like DNS vs. large database like Trisa's VASPs).
  - Suitability of data structures like Verifiable Claims and DIDs for capturing Gateway/owner identity.
  - The need for "asset profiles" to convey supported asset types by a Gateway, an area Dennis is continuing to work on.
  - Reference was made to the Monetary Authority of Singapore's Project Ubin, which highlights the need for "Gateways" for multi-network, multi-blockchain, multi-currency support, confirming the WG's direction.
ISO 20022 Standard:
- An update from Rama indicated that ISO 20022 primarily concerns message formats rather than asset definition or protocol, and doesn't directly impact SATP's core mission. It's not seen as duplicating the ISO standard but the WG should clarify SATP's uniqueness.
- John clarified that ISO 20022 is a broad messaging standard (XML-based, with JSON versions being explored) for traditional financial instruments (currency, stocks), not digital assets. It defines how to send payment orders, bank statements, etc.
- Discussion on whether SATP could reuse aspects of ISO 20022, such as agreed-upon data field descriptions/codes (e.g., country codes, currency codes) to avoid re-inventing.
- The challenge of referencing such a large, external, and normatively different standard within IETF documents was noted.
- A suggestion was made to directly engage with Swift's innovation group, as they are likely working on digital asset initiatives.
SATP Protocol Endpoints:
- Alex proposed having different API endpoints for each stage of the SATP protocol (e.g., commencement, lock, lock assertion) rather than a single Gateway endpoint.
- This approach could simplify implementation, allow for better load balancing, and align with REST standards. The question of whether this falls within the protocol or Gateway design was raised, but it was generally seen as relevant to the protocol.
Draft Overlap and HTTP Directorate Review:
- Lucas (via message) noted considerable overlap between the architecture document and the protocol specification. This was acknowledged as not surprising and potentially to be addressed by trimming the architecture document once the protocol is stable.
- An early review from the HTTP Protocol Directorate was received, which is unusual for new drafts but indicates the importance of HTTP semantics. Authors were advised to carefully consider these comments.
- The Chair explained the role of IETF directorates in reviewing drafts for specific expertise (e.g., HTTP, Security) and suggested the WG could request early reviews from relevant directorates in the future.
Meeting Platform: A brief discussion was held regarding the use of MeetEcho vs. Zoom for interim meetings. While Zoom might be perceived as easier to use by some, the benefits of MeetEcho's integration with IETF data tracker, automated blue sheets (attendance), and YouTube publishing were highlighted. A sense of those present indicated a preference to stick with MeetEcho for now unless significant problems arise.

Decisions and Action Items

Vocabulary/Glossary: Thomas and Claire will coordinate via the mailing list to discuss and decide on the long-term publication strategy (separate draft vs. architecture section).
Error Messages: A dedicated discussion/workshop on error message handling will be scheduled for the next (or an earlier) interim meeting. Thomas will coordinate logistics with Claire/West. The agenda for that interim meeting will be updated to reflect this focus.
SATP Protocol Endpoints: Alex will propose the idea of multi-stage API endpoints on the mailing list for further discussion.
ISO 20022: Martin and Thomas will seek out an expert with deep knowledge of ISO 20022 to understand its potential for reuse of data fields/codes and to determine if any messaging components could align with SATP.
HTTP Directorate Review: Authors are to read and carefully consider the comments received from the HTTP Protocol Directorate.

Next Steps

Schedule a focused interim meeting to discuss error message handling for SATP.
Further discussions on the mailing list regarding vocabulary publication and SATP protocol endpoints.
Continued work on Gateway identity identification, including asset profiles.
Investigation into specific data fields/codes within ISO 20022 that could be reused by SATP.
Addressing comments from the HTTP Protocol Directorate review.

Session Date/Time: 16 May 2023 14:00

SATP

Summary

Key Discussion Points

Agenda Review: The proposed agenda (author updates, ISO standards impact, other items) was adopted without objection.
Vocabulary/Glossary:
- The vocabulary is currently in a GitHub repository as part of the material.
- Discussion on long-term publication options:
  1. Leave in GitHub (least preferred by some).
  2. Publish as a separate Internet-Draft (might require minor charter adjustment but seen as feasible).
  3. Include as a section within the architecture document.
- A preference for formal publication as a separate document or within the architecture draft was noted for consistent reference.
Author Updates (Thomas):
- SATP Core (Error Messages): Work is in progress with Raphael and Martin to collect and categorize error messages, drawing inspiration from the TLS error model. The approach involves identifying potential failure points in each protocol stage (1, 2, 3) from an IT engineer's perspective.
- Gateway Identity Identification: Discussions with Shipping and Dennis are ongoing in a bi-weekly subgroup. Key aspects include:
  - Models for identification and discovery (hierarchical like DNS vs. large database like Trisa's VASPs).
  - Suitability of data structures like Verifiable Claims and DIDs for capturing Gateway/owner identity.
  - The need for "asset profiles" to convey supported asset types by a Gateway, an area Dennis is continuing to work on.
  - Reference was made to the Monetary Authority of Singapore's Project Ubin, which highlights the need for "Gateways" for multi-network, multi-blockchain, multi-currency support, confirming the WG's direction.
ISO 20022 Standard:
- An update from Rama indicated that ISO 20022 primarily concerns message formats rather than asset definition or protocol, and doesn't directly impact SATP's core mission. It's not seen as duplicating the ISO standard but the WG should clarify SATP's uniqueness.
- John clarified that ISO 20022 is a broad messaging standard (XML-based, with JSON versions being explored) for traditional financial instruments (currency, stocks), not digital assets. It defines how to send payment orders, bank statements, etc.
- Discussion on whether SATP could reuse aspects of ISO 20022, such as agreed-upon data field descriptions/codes (e.g., country codes, currency codes) to avoid re-inventing.
- The challenge of referencing such a large, external, and normatively different standard within IETF documents was noted.
- A suggestion was made to directly engage with Swift's innovation group, as they are likely working on digital asset initiatives.
SATP Protocol Endpoints:
- Alex proposed having different API endpoints for each stage of the SATP protocol (e.g., commencement, lock, lock assertion) rather than a single Gateway endpoint.
- This approach could simplify implementation, allow for better load balancing, and align with REST standards. The question of whether this falls within the protocol or Gateway design was raised, but it was generally seen as relevant to the protocol.
Draft Overlap and HTTP Directorate Review:
- Lucas (via message) noted considerable overlap between the architecture document and the protocol specification. This was acknowledged as not surprising and potentially to be addressed by trimming the architecture document once the protocol is stable.
- An early review from the HTTP Protocol Directorate was received, which is unusual for new drafts but indicates the importance of HTTP semantics. Authors were advised to carefully consider these comments.
- The Chair explained the role of IETF directorates in reviewing drafts for specific expertise (e.g., HTTP, Security) and suggested the WG could request early reviews from relevant directorates in the future.
Meeting Platform: A brief discussion was held regarding the use of MeetEcho vs. Zoom for interim meetings. While Zoom might be perceived as easier to use by some, the benefits of MeetEcho's integration with IETF data tracker, automated blue sheets (attendance), and YouTube publishing were highlighted. A sense of those present indicated a preference to stick with MeetEcho for now unless significant problems arise.

Decisions and Action Items

Vocabulary/Glossary: Thomas and Claire will coordinate via the mailing list to discuss and decide on the long-term publication strategy (separate draft vs. architecture section).
Error Messages: A dedicated discussion/workshop on error message handling will be scheduled for the next (or an earlier) interim meeting. Thomas will coordinate logistics with Claire/West. The agenda for that interim meeting will be updated to reflect this focus.
SATP Protocol Endpoints: Alex will propose the idea of multi-stage API endpoints on the mailing list for further discussion.
ISO 20022: Martin and Thomas will seek out an expert with deep knowledge of ISO 20022 to understand its potential for reuse of data fields/codes and to determine if any messaging components could align with SATP.
HTTP Directorate Review: Authors are to read and carefully consider the comments received from the HTTP Protocol Directorate.

Next Steps

Schedule a focused interim meeting to discuss error message handling for SATP.
Further discussions on the mailing list regarding vocabulary publication and SATP protocol endpoints.
Continued work on Gateway identity identification, including asset profiles.
Investigation into specific data fields/codes within ISO 20022 that could be reused by SATP.
Addressing comments from the HTTP Protocol Directorate review.

Session Date/Time: 16 May 2023 14:00

SATP

Summary

Key Discussion Points

Agenda Review: The proposed agenda (author updates, ISO standards impact, other items) was adopted without objection.
Vocabulary/Glossary:
- The vocabulary is currently in a GitHub repository as part of the material.
- Discussion on long-term publication options:
  1. Leave in GitHub (least preferred by some).
  2. Publish as a separate Internet-Draft (might require minor charter adjustment but seen as feasible).
  3. Include as a section within the architecture document.
- A preference for formal publication as a separate document or within the architecture draft was noted for consistent reference.
Author Updates (Thomas):
- SATP Core (Error Messages): Work is in progress with Raphael and Martin to collect and categorize error messages, drawing inspiration from the TLS error model. The approach involves identifying potential failure points in each protocol stage (1, 2, 3) from an IT engineer's perspective.
- Gateway Identity Identification: Discussions with Shipping and Dennis are ongoing in a bi-weekly subgroup. Key aspects include:
  - Models for identification and discovery (hierarchical like DNS vs. large database like Trisa's VASPs).
  - Suitability of data structures like Verifiable Claims and DIDs for capturing Gateway/owner identity.
  - The need for "asset profiles" to convey supported asset types by a Gateway, an area Dennis is continuing to work on.
  - Reference was made to the Monetary Authority of Singapore's Project Ubin, which highlights the need for "Gateways" for multi-network, multi-blockchain, multi-currency support, confirming the WG's direction.
ISO 20022 Standard:
- An update from Rama indicated that ISO 20022 primarily concerns message formats rather than asset definition or protocol, and doesn't directly impact SATP's core mission. It's not seen as duplicating the ISO standard but the WG should clarify SATP's uniqueness.
- John clarified that ISO 20022 is a broad messaging standard (XML-based, with JSON versions being explored) for traditional financial instruments (currency, stocks), not digital assets. It defines how to send payment orders, bank statements, etc.
- Discussion on whether SATP could reuse aspects of ISO 20022, such as agreed-upon data field descriptions/codes (e.g., country codes, currency codes) to avoid re-inventing.
- The challenge of referencing such a large, external, and normatively different standard within IETF documents was noted.
- A suggestion was made to directly engage with Swift's innovation group, as they are likely working on digital asset initiatives.
SATP Protocol Endpoints:
- Alex proposed having different API endpoints for each stage of the SATP protocol (e.g., commencement, lock, lock assertion) rather than a single Gateway endpoint.
- This approach could simplify implementation, allow for better load balancing, and align with REST standards. The question of whether this falls within the protocol or Gateway design was raised, but it was generally seen as relevant to the protocol.
Draft Overlap and HTTP Directorate Review:
- Lucas (via message) noted considerable overlap between the architecture document and the protocol specification. This was acknowledged as not surprising and potentially to be addressed by trimming the architecture document once the protocol is stable.
- An early review from the HTTP Protocol Directorate was received, which is unusual for new drafts but indicates the importance of HTTP semantics. Authors were advised to carefully consider these comments.
- The Chair explained the role of IETF directorates in reviewing drafts for specific expertise (e.g., HTTP, Security) and suggested the WG could request early reviews from relevant directorates in the future.
Meeting Platform: A brief discussion was held regarding the use of MeetEcho vs. Zoom for interim meetings. While Zoom might be perceived as easier to use by some, the benefits of MeetEcho's integration with IETF data tracker, automated blue sheets (attendance), and YouTube publishing were highlighted. A sense of those present indicated a preference to stick with MeetEcho for now unless significant problems arise.

Decisions and Action Items

Vocabulary/Glossary: Thomas and Claire will coordinate via the mailing list to discuss and decide on the long-term publication strategy (separate draft vs. architecture section).
Error Messages: A dedicated discussion/workshop on error message handling will be scheduled for the next (or an earlier) interim meeting. Thomas will coordinate logistics with Claire/West. The agenda for that interim meeting will be updated to reflect this focus.
SATP Protocol Endpoints: Alex will propose the idea of multi-stage API endpoints on the mailing list for further discussion.
ISO 20022: Martin and Thomas will seek out an expert with deep knowledge of ISO 20022 to understand its potential for reuse of data fields/codes and to determine if any messaging components could align with SATP.
HTTP Directorate Review: Authors are to read and carefully consider the comments received from the HTTP Protocol Directorate.

Next Steps

Schedule a focused interim meeting to discuss error message handling for SATP.
Further discussions on the mailing list regarding vocabulary publication and SATP protocol endpoints.
Continued work on Gateway identity identification, including asset profiles.
Investigation into specific data fields/codes within ISO 20022 that could be reused by SATP.
Addressing comments from the HTTP Protocol Directorate review.

Session Date/Time: 16 May 2023 14:00

SATP

Summary

Key Discussion Points

Agenda Review: The proposed agenda (author updates, ISO standards impact, other items) was adopted without objection.
Vocabulary/Glossary:
- The vocabulary is currently in a GitHub repository as part of the material.
- Discussion on long-term publication options:
  1. Leave in GitHub (least preferred by some).
  2. Publish as a separate Internet-Draft (might require minor charter adjustment but seen as feasible).
  3. Include as a section within the architecture document.
- A preference for formal publication as a separate document or within the architecture draft was noted for consistent reference.
Author Updates (Thomas):
- SATP Core (Error Messages): Work is in progress with Raphael and Martin to collect and categorize error messages, drawing inspiration from the TLS error model. The approach involves identifying potential failure points in each protocol stage (1, 2, 3) from an IT engineer's perspective.
- Gateway Identity Identification: Discussions with Shipping and Dennis are ongoing in a bi-weekly subgroup. Key aspects include:
  - Models for identification and discovery (hierarchical like DNS vs. large database like Trisa's VASPs).
  - Suitability of data structures like Verifiable Claims and DIDs for capturing Gateway/owner identity.
  - The need for "asset profiles" to convey supported asset types by a Gateway, an area Dennis is continuing to work on.
  - Reference was made to the Monetary Authority of Singapore's Project Ubin, which highlights the need for "Gateways" for multi-network, multi-blockchain, multi-currency support, confirming the WG's direction.
ISO 20022 Standard:
- An update from Rama indicated that ISO 20022 primarily concerns message formats rather than asset definition or protocol, and doesn't directly impact SATP's core mission. It's not seen as duplicating the ISO standard but the WG should clarify SATP's uniqueness.
- John clarified that ISO 20022 is a broad messaging standard (XML-based, with JSON versions being explored) for traditional financial instruments (currency, stocks), not digital assets. It defines how to send payment orders, bank statements, etc.
- Discussion on whether SATP could reuse aspects of ISO 20022, such as agreed-upon data field descriptions/codes (e.g., country codes, currency codes) to avoid re-inventing.
- The challenge of referencing such a large, external, and normatively different standard within IETF documents was noted.
- A suggestion was made to directly engage with Swift's innovation group, as they are likely working on digital asset initiatives.
SATP Protocol Endpoints:
- Alex proposed having different API endpoints for each stage of the SATP protocol (e.g., commencement, lock, lock assertion) rather than a single Gateway endpoint.
- This approach could simplify implementation, allow for better load balancing, and align with REST standards. The question of whether this falls within the protocol or Gateway design was raised, but it was generally seen as relevant to the protocol.
Draft Overlap and HTTP Directorate Review:
- Lucas (via message) noted considerable overlap between the architecture document and the protocol specification. This was acknowledged as not surprising and potentially to be addressed by trimming the architecture document once the protocol is stable.
- An early review from the HTTP Protocol Directorate was received, which is unusual for new drafts but indicates the importance of HTTP semantics. Authors were advised to carefully consider these comments.
- The Chair explained the role of IETF directorates in reviewing drafts for specific expertise (e.g., HTTP, Security) and suggested the WG could request early reviews from relevant directorates in the future.
Meeting Platform: A brief discussion was held regarding the use of MeetEcho vs. Zoom for interim meetings. While Zoom might be perceived as easier to use by some, the benefits of MeetEcho's integration with IETF data tracker, automated blue sheets (attendance), and YouTube publishing were highlighted. A sense of those present indicated a preference to stick with MeetEcho for now unless significant problems arise.

Decisions and Action Items

Vocabulary/Glossary: Thomas and Claire will coordinate via the mailing list to discuss and decide on the long-term publication strategy (separate draft vs. architecture section).
Error Messages: A dedicated discussion/workshop on error message handling will be scheduled for the next (or an earlier) interim meeting. Thomas will coordinate logistics with Claire/West. The agenda for that interim meeting will be updated to reflect this focus.
SATP Protocol Endpoints: Alex will propose the idea of multi-stage API endpoints on the mailing list for further discussion.
ISO 20022: Martin and Thomas will seek out an expert with deep knowledge of ISO 20022 to understand its potential for reuse of data fields/codes and to determine if any messaging components could align with SATP.
HTTP Directorate Review: Authors are to read and carefully consider the comments received from the HTTP Protocol Directorate.

Next Steps

Schedule a focused interim meeting to discuss error message handling for SATP.
Further discussions on the mailing list regarding vocabulary publication and SATP protocol endpoints.
Continued work on Gateway identity identification, including asset profiles.
Investigation into specific data fields/codes within ISO 20022 that could be reused by SATP.
Addressing comments from the HTTP Protocol Directorate review.

Session Date/Time: 16 May 2023 14:00

SATP

Summary

Key Discussion Points

Agenda Review: The proposed agenda (author updates, ISO standards impact, other items) was adopted without objection.
Vocabulary/Glossary:
- The vocabulary is currently in a GitHub repository as part of the material.
- Discussion on long-term publication options:
  1. Leave in GitHub (least preferred by some).
  2. Publish as a separate Internet-Draft (might require minor charter adjustment but seen as feasible).
  3. Include as a section within the architecture document.
- A preference for formal publication as a separate document or within the architecture draft was noted for consistent reference.
Author Updates (Thomas):
- SATP Core (Error Messages): Work is in progress with Raphael and Martin to collect and categorize error messages, drawing inspiration from the TLS error model. The approach involves identifying potential failure points in each protocol stage (1, 2, 3) from an IT engineer's perspective.
- Gateway Identity Identification: Discussions with Shipping and Dennis are ongoing in a bi-weekly subgroup. Key aspects include:
  - Models for identification and discovery (hierarchical like DNS vs. large database like Trisa's VASPs).
  - Suitability of data structures like Verifiable Claims and DIDs for capturing Gateway/owner identity.
  - The need for "asset profiles" to convey supported asset types by a Gateway, an area Dennis is continuing to work on.
  - Reference was made to the Monetary Authority of Singapore's Project Ubin, which highlights the need for "Gateways" for multi-network, multi-blockchain, multi-currency support, confirming the WG's direction.
ISO 20022 Standard:
- An update from Rama indicated that ISO 20022 primarily concerns message formats rather than asset definition or protocol, and doesn't directly impact SATP's core mission. It's not seen as duplicating the ISO standard but the WG should clarify SATP's uniqueness.
- John clarified that ISO 20022 is a broad messaging standard (XML-based, with JSON versions being explored) for traditional financial instruments (currency, stocks), not digital assets. It defines how to send payment orders, bank statements, etc.
- Discussion on whether SATP could reuse aspects of ISO 20022, such as agreed-upon data field descriptions/codes (e.g., country codes, currency codes) to avoid re-inventing.
- The challenge of referencing such a large, external, and normatively different standard within IETF documents was noted.
- A suggestion was made to directly engage with Swift's innovation group, as they are likely working on digital asset initiatives.
SATP Protocol Endpoints:
- Alex proposed having different API endpoints for each stage of the SATP protocol (e.g., commencement, lock, lock assertion) rather than a single Gateway endpoint.
- This approach could simplify implementation, allow for better load balancing, and align with REST standards. The question of whether this falls within the protocol or Gateway design was raised, but it was generally seen as relevant to the protocol.
Draft Overlap and HTTP Directorate Review:
- Lucas (via message) noted considerable overlap between the architecture document and the protocol specification. This was acknowledged as not surprising and potentially to be addressed by trimming the architecture document once the protocol is stable.
- An early review from the HTTP Protocol Directorate was received, which is unusual for new drafts but indicates the importance of HTTP semantics. Authors were advised to carefully consider these comments.
- The Chair explained the role of IETF directorates in reviewing drafts for specific expertise (e.g., HTTP, Security) and suggested the WG could request early reviews from relevant directorates in the future.
Meeting Platform: A brief discussion was held regarding the use of MeetEcho vs. Zoom for interim meetings. While Zoom might be perceived as easier to use by some, the benefits of MeetEcho's integration with IETF data tracker, automated blue sheets (attendance), and YouTube publishing were highlighted. A sense of those present indicated a preference to stick with MeetEcho for now unless significant problems arise.

Decisions and Action Items

Vocabulary/Glossary: Thomas and Claire will coordinate via the mailing list to discuss and decide on the long-term publication strategy (separate draft vs. architecture section).
Error Messages: A dedicated discussion/workshop on error message handling will be scheduled for the next (or an earlier) interim meeting. Thomas will coordinate logistics with Claire/West. The agenda for that interim meeting will be updated to reflect this focus.
SATP Protocol Endpoints: Alex will propose the idea of multi-stage API endpoints on the mailing list for further discussion.
ISO 20022: Martin and Thomas will seek out an expert with deep knowledge of ISO 20022 to understand its potential for reuse of data fields/codes and to determine if any messaging components could align with SATP.
HTTP Directorate Review: Authors are to read and carefully consider the comments received from the HTTP Protocol Directorate.

Next Steps

Schedule a focused interim meeting to discuss error message handling for SATP.
Further discussions on the mailing list regarding vocabulary publication and SATP protocol endpoints.
Continued work on Gateway identity identification, including asset profiles.
Investigation into specific data fields/codes within ISO 20022 that could be reused by SATP.
Addressing comments from the HTTP Protocol Directorate review.