Re: Why I can no longer support OAuth2 (was: Re: Why can't I pay using a Verifiable Credential?)

We're launching a new working group at DIF focused on evaluating approaches
toward trusted AI Agents. One of our initial work items is exploring Agent
Authority Use Cases, where we'll assess how current models, such as oAuth2,
align with agents across a variety of scenarios.

We'll also be looking deeply at object capabilities/zcaps ( and whatever
else looks promising ).

We're holding chair elections early this week. If you're interested in
running, you're more than welcome to put your name forward.

- Andor

On Sun, Aug 17, 2025, 11:05 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> ne 17. 8. 2025 v 18:54 odesílatel Manu Sporny <msporny@digitalbazaar.com>
> napsal:
>
>> On Wed, Aug 13, 2025 at 5:18 PM Tim Bouma <trbouma@gmail.com> wrote:
>> > Several months back I took a hard look at OAuth and what I learned from
>> my implementation endeavour, I wrote this.
>> >
>> >
>> https://open.substack.com/pub/trbouma/p/why-i-can-no-longer-support-oauth
>>
>> This is an excellent article, Tim. It matches our experience at
>> Digital Bazaar implementing both OAuth2 and the OID4VCI/OID4VP
>> protocols. We have repeatedly experienced developers in the ecosystem
>> accidentally leak their credentials via OAuth2 because of a lack of
>> understanding in how it works, or the pitfalls with "framework-based
>> standards".
>>
>> OAuth2 was what drove us to incubate and standardize HTTP Signatures,
>> which does at least depend on cryptography to prove authorization.
>>
>> Dick Hardt has recently written a related post on how OAuth2 is not a
>> good fit for things like MCP (and how HTTP Message Signatures are
>> better):
>>
>>
>> https://www.linkedin.com/posts/dickhardt_mcp-oauth-ai-activity-7358178115673616384-RKzc/
>>
>> ... granted, he still tries to loop OAuth2 back into the mix (a
>> mistake, IMHO -- we should just leave OAuth2 behind and move on to
>> stuff like Authorization Capabilities), but dropping the complicated
>> OAuth2 dances for clients is certainly an improvement.
>>
>> In any case, just wanted to echo what you wrote Tim -- OAuth2 was
>> better than sharing passwords a decade or more ago, but we need to
>> move on to real cryptographic authentication, authorization, and
>> delegation.
>>
>
> Manu, Tim, Will,
>
> Nice thread. You may be interested in a small auth spec I’ve been drafting
> in the Nostr CG:
>
> https://nostrcg.github.io/http-schnorr-auth/
>
> It builds on NIP-98 (which I co-authored with Kieran) and adds guidance on
> using it with WebID and Solid OIDC (with an eye toward REC next year). The
> goal is simple, cryptographic request auth with optional delegation.
>
> Manu may remember the work we started around 2008; perhaps this ties the
> pieces back together: DID, WebID, Solid, and VCs, in a web-native way
> (finally!).
>
> I have working implementations and a bridge to Solid, and NIP-98 is
> already live in a number of Nostr apps, deployed to the high thousands of
> users. Happy to compare notes or align with related efforts w/ signatures
> etc.
>
> Best,
> Melvin
>
>
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> https://www.digitalbazaar.com/
>>
>>