Closed kdenhartog closed 4 years ago
its super outdated.
we froze it for plugfest, I'm hoping we can consoldiate the apis... like we have done here: https://transmute-industries.github.io/vc-http-api/
https://transmute-industries.github.io/vc-http-api/versions/v0.0.0/index.html
generally the security is not a concern for these APIs... its can be handled however vendors want. for now we are just trying to agree to the endpoints, inputs and outputs.
we consider these APIs to be "internal" in the sense that vendors decide how they want to secure them, and that they are mean to be called by trusted clients (the vendor controls)
Makes sense to take it one step at a time and not imply use of additional technologies (OIDC deployment for JWTs, key management for HTTP Sigs, self signed certs for MTLS, and network configuration for security at the network layer). Would there be a good place to put these as considerations for a deployment?
on your equivalent of your vendor repo IMO, ours is https://vc.transmute.world/api/docs/static/index.html
^ its fully open / no auth required / docker image cloud function / no persistence.
Found a description of this here: https://github.com/w3c-ccg/vc-issuer-http-api/blob/master/architecture.md#api-security
I was looking at the yaml doc just a bit ago and noticed there wasn't any definitions around securing the API endpoints with something like a JWT or HTTP signature. Is the assumption that this API will be deployed in a secured network environment where only particular IP addresses can hit this endpoint or is there other aspects that are being considered that I've missed?