Okap is not a standard, it isn't even a secure protocol. It is just a pattern/architecture which intentionally avoids using oauth2 because oauth2 requires the apps to support it, and of course getting those providers to support oauth2 is non trivial.
It wound be nice if the providers supported oauth2, but they don't really care about security. If they did take that perspective, and there was something getting in the way of them support oauth, that would be good to find out. On Fri, Dec 26, 2025, 10:28 Hemanth H.M <[email protected]> wrote: > 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]
