[Sat] Request for feedback on API1

[Rafael Belchior <[e-mail]>]

Hello folks,
We have been refactoring SATP-Core, which is available here: 
https://github.com/ietf-satp/draft-ietf-satp-core. The latest version 
(editor's copy) is this: 
https://ietf-satp.github.io/draft-ietf-satp-core/draft-ietf-satp-core.html.

We have moved API1 (gateway client to gateway) and API3 (gateway to 
third-party APIs/services) to the Appendix (as it is not "core", such as 
API2 which is gateway to gateway).

The definition of an API for gateway clients is of utmost importance so 
we can create a specification of how applications talk to gateway. 
Without this specification, vendor lock is more likely, as well as a 
lower variety of implementations to be adopted.

I have put together a proposal for API1 within Hyperledger Cacti:  
https://github.com/hyperledger/cacti/blob/satp-dev/packages/cactus-plugin-satp-hermes/src/main/yml/bol/openapi-blo-bundled.yml 
(you can copy-paste the spec into https://editor.swagger.io/ and 
visualize it).

This API defines a few endpoints, that have admin or transactional 
functionalities:

Transaction
- transact (Submits a transaction intent)
- cancel (Cancels a transaction session)
- routes (Get a list of routes for a gateway-to-gateway asset transfer)
- integrations (gets list of supported chains/infrastructure)

Admin
cancel, continue, pause and audit.

Questions for chairs and contributors:
- Should we extract the API1 considerations into their own 
document/draft, or leave it at the appendix? I would be happy to lead 
this effort.

-What does the gateway interface need in terms of application context? 
How is the context defined?

-What would be desirable in terms of audit data for the client 
application?


Cheers,

-- 
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/