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

Managing DIDs is a job in itself. Unless the management reduces some other
task or cost.

-Adrian

On Wed, Aug 13, 2025 at 6:42 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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