Risk and Security model is unclear - token based authentication is insufficient for all cases where it is allowed

[AramZS]

Right now this specification is missing a risk model and I don't feel confident in my understanding of all sides of the system to write one myself, however, it strikes me that token based authentication may be sufficient for some cases (like getting products) but not for others. Because the system generally modeled supposes that the endpoints a system hits are stable we must trust retention of domains with zero issues.

What happens if the domain expires and the provider/vendor/platform on the other side has lost their domain temporarily to an attacker? Now that attacker has captured all of these tokens and done so without the client knowing what has occurred. Since this is a public standard, emulating the expected response is trivial. The same is true if someone can achieve a man-in-the-middle status.

OAuth is mentioned in the security flow, but current documentation does not require it. The specification should identify areas where data leakage is risky, like reporting (at the very least), and specify that those endpoints require OAuth (seems the best option considering its use in MCP) or some other two sided handshake approach.

[bokelley]

Thanks for raising these important security considerations, @AramZS.

We're escalating this to the AdCP technical working group for discussion on whether to mandate OAuth for high-risk operations.

In the meantime, we're updating the security documentation to:

1. Add a Risk Classification section that categorizes operations by risk level (discovery, data access, financial)
2. Strengthen the OAuth recommendation to SHOULD for financial operations (create_media_buy, update_media_buy)
3. Document the specific risks of bearer token authentication (domain hijacking, token interception)
4. Add guidance on additional mitigations (certificate pinning, domain verification)

You're right that bearer tokens are common across the industry, but the financial nature of AdCP operations warrants stronger guidance. The spec will remain flexible (supporting API keys for server-to-server scenarios), but we'll make the risks and recommendations clearer.

PR incoming with documentation updates.