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]
