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

st 13. 8. 2025 v 22:46 odesílatel Adrian Gropper <agropper@healthurl.com>
napsal:

> 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?
>

I would personally use a did: method to denote a user.  Then a VC, or
something like a VC, to sign an asset or a payment from one party to
another.

In this way the controller of the DID can have a balance and then transfer
part of that balance to the controller of another DID.

The VC itself might need to be tweaked, or rather use the canonicalization
algorithm, and the signing part of the BIP340 spec.


>
> - 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
>>>>
>>>