The biggest misconception here is that the client or requester is responsible for the keys. They aren’t. They can be but ideally a signed response from the service with a key is ideal. Still, a client header key is better than no key.
In situations where it’s fire and forget, like payments, it’s fine to generate a deterministic key from the requesters side. In situations where transactions or escrow is in play, it’s best to request from the service so the service can orchestrate.
But I’m not a CTO, just an engineer. I can’t spin bad decisions into “features” like they can. Or small novel fixes as profound advances to the industry.
Comments
The biggest misconception here is that the client or requester is responsible for the keys. They aren’t. They can be but ideally a signed response from the service with a key is ideal. Still, a client header key is better than no key.
In situations where it’s fire and forget, like payments, it’s fine to generate a deterministic key from the requesters side. In situations where transactions or escrow is in play, it’s best to request from the service so the service can orchestrate.
But I’m not a CTO, just an engineer. I can’t spin bad decisions into “features” like they can. Or small novel fixes as profound advances to the industry.