Isn't the whole point to delegate API access to a third party? That's exactly what OAuth provides!
On Fri, Dec 26, 2025, 17:29 Hemanth H.M <[email protected]> wrote: > Hmm, how does it solve what OKAP is proposing even if the providers > implement oauth? > > -- > Thank you, > Hemanth.HM <http://www.h3manth.com> > > > > On Fri, Dec 26, 2025 at 3:19 AM Warren Parad <[email protected]> wrote: > >> What's stopping the providers from just supporting out of the box oauth2, >> doesn't that solve all the problems here? >> >> On Fri, Dec 26, 2025, 11:15 Hemanth H.M <[email protected]> wrote: >> >>> I am the author of OKAP, intially I wanted to extend oauth but then >>> decided to keep it independent and see how it goes. >>> >>> Few in the public domain were pro RFC… >>> >>> Adaption is the greatest challenge. >>> >>> -- >>> Thank you, >>> Hemanth.HM <http://www.h3manth.com> >>> >>> >>> >>> On Fri, Dec 26, 2025 at 2:55 AM Warren Parad <[email protected]> wrote: >>> >>>> 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]
