It is an extremely terrible idea to create a structure for scopes. I've done this several times in different ecosystems and it always starts out ok but falls apart quickly. Do not repeat this mistake.
If you need structure for access, define a RAR type, that's what it's there for. - Justin ________________________________ From: Hemanth H.M <[email protected]> Sent: Wednesday, December 24, 2025 4:41 PM To: [email protected] <[email protected]> Subject: [OAUTH-WG] [New I-D] draft-hemanth-oauth-ai-scopes-00 - OAuth 2.0 Extension for AI Model Access Hi OAuth WG, I've submitted a new Internet-Draft for your consideration: draft-hemanth-oauth-ai-scopes-00 - OAuth 2.0 Extension for AI Model Access Problem: AI model APIs (OpenAI, Anthropic, Google, etc.) require API key delegation, but current practices involve sharing master keys directly with third-party applications—no scoping, no revocation, no usage limits. Proposal: Extend OAuth 2.0 with: 1. Standard scope syntax: ai:<provider>:<model>:<capability> 2. Token metadata for spend/rate limits 3. Token introspection extensions for usage tracking 4. Security considerations (DPoP/mTLS for high-security deployments) GitHub: https://github.com/hemanth/oauth-ai-scopes I'd welcome feedback on the scope syntax, alignment with existing OAuth extensions (RFC 8707, RFC 9449), and whether this is something the WG would consider adopting. P.S: I also started https://okap.dev as a separate protocol, in case... -- Thank you, Hemanth.HM<http://www.h3manth.com>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
