Production utilities endpoints

[PatStLouis]

Does the VC-API spec take into consideration endpoints which could be used for production deployment or is this left to the implementer?

Examples could include:

• server.liveness (k8s liveness probe)
• server.readiness (k8s readiness probe)
• server.configuration (running configuration, such as proof type, cryptographic suite used, endpoints, ports, labels, etc...)
• server.status (metrics for uptime, online, etc)

[dlongley]

I think we should do our best to ensure that the VC API does not create problems for these approaches, however, it shouldn't specify how to do them, instead leaving them to implementations.

[PatStLouis]

@dlongley thanks for your input, happy to close this issue if this is deemed out of scope

[msporny]

The group discussed this on 2023-07-11. @PatStLouis provided an introduction to the topic. He noted that this is probably out of scope, but should be discussed. This was meant for use cases where you deploy the application via Kubernetes... VC API spec doesn't say you are limited to the endpoints it specifies, you can have more, including the endpoints listed above.
@dlongley agreed. @PatStLouis noted that an interesting thing is a configuration endpoint could be implemented... "this instance uses X type of signature, this other instance uses Y type of signature and Z DID". For example "GET /config" -- and formal mechanism of getting those values... the fields in the options, since we don't provide them as options anymore, maybe express them via that mechanism. @dlongley noted that it's being tracked in issue #267 (comment). There was a discussion on what the paths would be "GET .../instance/INSTANCE_ID/" would give you a configuration.

There was agreement to close the issue and pick up the configuration issue in #267.