Re: Why can't I pay using a Verifiable Credential?

I developed a payments wallet to send and receive funds and I realized I
could use the same mechanisms to offer and share records.

Now, I’m extending this protocol to offer and share records (credentials,
as you may wish to call them, but it applies to any record)

https://nwc.dev/


And this just got published today for communicating between agents

https://www.contextvm.org/faqs

We’re seeing this all converge into a simple protocol where payments are
native and you don’t need all that infrastructure required for OAuth.

Have a close look at the FAQ tab: Comparison: Traditional Remote MCP vs
ContextVM

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?r=3r59&utm_medium=ios


On Wed, Aug 13, 2025 at 4:46 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> This is exactly what I was hoping to understand!
> - Thank you to Anders for pointing out the user experience and the role of
> P2P payments that may not be subject to KYC.
> - Thank you to Melvin for pointing out NWC as a potential, relatively
> simple answer to my question and the impact of stablecoins as a part of a
> scalable solution.
> - Thank you to Tim for pointing out why OAuth is not appropriate for the
> payments use-case and endorsing NWC.
>
> I have no investment in either TLS, NWC, or OAuth / UMA2. As a delegated
> authorization protocol GNAP, I think, solves many if not all of the
> security and implementation issues with OAuth and does accept VCs as part
> of a standardized request format.
>
> Given emerging standards for MCP, A2A, and P2P payments, what should be
> the role of Verifiable Credentials, if any?
>
> - Adrian
>
> On Tue, Aug 12, 2025 at 8:24 AM Tim Bouma <trbouma@gmail.com> wrote:
>
>> It’s what I learned from implementing Nostr Wallet Connect that prompted
>> me to write this post. I’ve been expanding the protocol to offer and share
>> records, which prompted me to review the family of protocols from OAuth2.0.
>>
>> I realized what was a great tradeoff decision in 2012, delegating
>> security to the TLS pipes, no longer holds. Too many seams and external
>> dependencies. I also concluded that there was no longer a need to have
>> separate entities for Client, Authorization Server, and Relying Party
>> because you could reduce the flow down to two equally capable
>> counterpartied.
>>
>> All said, OAuth is still fine for the current generation of solutions,
>> but now I am looking past this horizon where every party in an interaction
>> needs to be cryptographically assured from end to end. OAuth goes part way,
>> and there are some great enhancements, but no longer enough.
>>
>> As for payments, that was the starting point of my project. I am now
>> expanding into sharing of records with Nostr Wallet Connect.
>>
>>
>> https://open.substack.com/pub/trbouma/p/why-i-can-no-longer-support-oauth
>> <https://open.substack.com/pub/trbouma/p/why-i-can-no-longer-support-oauth?r=3r59&utm_medium=ios>
>>
>> On Tue, Aug 12, 2025 at 2:34 AM Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> út 12. 8. 2025 v 3:00 odesílatel Adrian Gropper <agropper@healthurl.com>
>>> napsal:
>>>
>>>> I'm so tired of Venmo.
>>>>
>>>
>>> Might be closer than you think.
>>>
>>> Now that we have did:nostr and BIP340 VCs it should be fairly
>>> straightforward to do payments.  Here is an example use case:
>>>
>>> https://bitcoinmagazine.com/technical/nostr-wallet-connect-bitcoin-usb
>>>
>>>
>>>>
>>>> - Adrian
>>>>
>>>