Maybe off topic, but https://okap.dev sounds ok?
-- Thank you, Hemanth.HM <http://www.h3manth.com> On Thu, Dec 25, 2025 at 10:55 PM Warren Parad <[email protected]> wrote: > Authorization to specific models doesn't need to live inside the the > oauth2 generated JWT. OAuth is not the appropriate place for that. > > On Thu, Dec 25, 2025, 21:36 Hemanth H.M <[email protected]> wrote: > >> Hey Warren, >> >> Good question. Current OAuth doesn't have a standard way to scope access >> *to specific models* or attach usage limits (spend/rate) directly to the >> token metadata without heavy custom extensions, right? This ID tries to >> standardize that delegation layer. >> >> Justin, We can leverage RAR type for this? >> >> >> -- >> Thank you, >> Hemanth.HM <http://www.h3manth.com> >> >> >> >> On Thu, Dec 25, 2025 at 1:31 PM Justin Richer <[email protected]> wrote: >> >>> 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] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
