4 ms·
It seems you were correct that I was confused. This comment didn't help me discover that but this[0] one in combination with rereading did. In that context, y
by erikerikson 1y ago
It seems you were correct that I was confused. This comment didn't help me discover that but this[0] one in combination with rereading did.
In that context, you're right that I was more confused than now but I disagree that the client-server requirements for confidentiality and authenticity are the same.
In the case of webhooks the sender does not want to include breach of the receiver in their threat model. The consequences of and ability to detect malicious API calls to service are different than those of malicious calls claiming to be from a service. A shared secret removes the potential for detection from the service while asynchronous key signing does not.
[0] https://news.ycombinator.com/item?id=44108512 https://news.ycombinator.com/item?id=44108512
- mfbx9da4 1y ago> A shared secret removes the potential for detection from the service while asynchronous key signing does not. I would approximate that 95% of the time when a webhook sender discusses signatures they are referring to HMAC (symmetric-key signing). There is a clear benefit to asymmetric-key signatures but that's not the focus of this article. It's discussing the industry convention of using symmetric-key signing.