Service Info API sever decoupling: a discussion

[7flying]

This issue is simply to discuss the pros and cons of having the Service Info API server implementation decoupled from the Owner Onboarding server.
Should we merge them? Should we leave them as they are?

[miabbott]

Instead of an issue, let's just convert this to a discussion topic?

There's a handy Convert to discussion link at the bottom right

[miabbott]

@mmartinv I believe you raised this issue originally; could you share your thoughts/questions?

[mmartinv]

According to the FIDO Onboard specification, the ServiceInfo messages are exchanged between the Device and the Owner's onboarding server and is the way to customize/configure the Device and its Management Agent. This interaction occurs only once in the device lifetime, during the final stage of the Transfer of Ownership 2 (TO2) protocol.

The implementation of this part of the specification was moved to the ServiceInfo API Server by defining a non-standard REST API between the Owner's onboarding server and the ServiceInfo API Server. From my point of view this is hard to justify and adds complexity to the implementation with little/no benefits.

The implementation of additional FSIMs will require big changes in the ServiceInfo API Server to allow the bidirectional exchange of messages so I think this is the chance to merge the ServiceInfo API Server into Owner's onboarding server and simplify things.

[7flying]

Merging service info API server with Owner onboarding server:

PROS

• Adds less complexity
• One less API to maintain

CONS

• Less scalable (?¿)
  • Related to reading config: Not really since we will be using a DB
  • Related to performance: the devices are still connecting to the owner as they were before, there weren’t two separate endpoints to connect based on the request type.
• At the time of writing, requires restart for configuration
  • Minor: fswatcher(s) in rust are easy https://github.com/notify-rs/notify

The team agrees on the merge, see issue #622