3 ms·
Could you expand on the reasoning behind your comments a bit more—specifically why this is bad for APIs? I’m sure the OP and plenty of others would appreciate
by bobwaycott 7y ago
Could you expand on the reasoning behind your comments a bit more—specifically why this is bad for APIs?
I’m sure the OP and plenty of others would appreciate it.
- detaro 7y agoThese arguments apply pretty much universally. If you want an additional ones specific to APIs: People will likely want to talk to your API from all kinds of environments/languages, and existence and quality of crypto APIs in those will vary widely. It's also not something that's commonly done, so developers are unfamiliar with it, which increases both their frustration and the risk they make mistakes. If you talk to public APIs, you're probably at some point encountering OAuth. It's not an accident that OAuth 2 has gotten rid of crypto and instead leaves it to the transport (HTTPS), where people are familiar with its use, nearly always have libraries etc available that handle it correctly for them, and upgrades on that layer, e.g. to new TLS versions, do not require OAuth 2 to change.