Re: Web Payments and voucher URIs

On Mon, 19 Aug 2019 at 19:52, Andrew Bransford Brown <andrewbb@gmail.com>
wrote:

> Could you use a GUID?
>

Yes I could.  And typically you would.

In fact there already exists

urn:uuid:

Which would be one choice.  However, it's a bit broad.


>
> Send the GUID to the user (email?).  The user can check the balance.  The
> user can spend it.
>

Exactly.  Send to email.  Send over SMS.  Send over chat.  Or even print
out a QR code or scratch card.  Many ways.


>
>
> I suppose the GUID could be stolen, but the user would complain.
>

Same applies to the game vouchers you see in super markets.  These are
designed as one use vouchers.  I'll note here that cash can also be
stolen.  That's essentially what we're making here.  Digital cash.


>
> On Mon, Aug 19, 2019 at 1:49 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Mon, 19 Aug 2019 at 08:38, Michiel de Jong <michiel@unhosted.org>
>> wrote:
>>
>>> Hi Melvin,
>>>
>>> Great topic! I like how the scheme is very generic, but maybe at the
>>> same time that's a downside, because how would you dereference
>>> 'urn:voucher:12345abcd ...'?
>>>
>>
>> urns are typically not derefencable but you could write a spec to
>> dereference it at /.well-known/voucher/ID if you wanted to
>>
>> and then put it here :
>> https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
>>
>>
>>> Maybe start by base64-decoding it?
>>>
>>
>> I didnt specify an coding, tho it was perhaps implied.  This is something
>> it could be neat to spec.  Right now it's just a string.  Should it be
>> unicode I wondered?
>>
>>
>>> But what would you see then, and how would that refer to a party who is
>>> willing to "cash" the voucher?
>>>
>>
>> The party cashing is orthogonal, in this case you are overloading the
>> identifier to be both an ID and a shared secret.  A capability URI as such,
>> but without the HTTP.
>>
>>
>> https://www.slideshare.net/dappelquist/capability-ur-ls-for-london-web-standards
>>
>> Bitcoin does this too, but overloading IDs and public key hashes.
>>
>>
>>> There could be some indication of some account identifier at some
>>> ledger, but for that, you would need some more mechanics than just the
>>> opaque URI scheme. An interesting approach to that problem is Interledger
>>> addresses, for instance.
>>>
>>
>> Im starting with just a simple csv or JSON which will be like the "1 star
>> of payments", easy enough to get up and running.
>>
>>
>>>
>>> I would say there are generally two types of vouchers, relational (where
>>> the issuer has some social connection to the redeemer) and anonymous
>>>
>>
>> I think im starting out here with anonymous by implication.
>>
>>
>>> (where the voucher has a more universal value, against some anonymous
>>> "bubble"). If you're interested in peer-to-peer vouchers rather than
>>> anonymous ones, then may I take this opportunity to plug the Network Money
>>> mailing list I started last year, particularly this post in which I
>>> concluded that maybe peer-to-peer money is in the end not really what
>>> people want:
>>> https://groups.google.com/forum/#!topic/network-money/Z2zAyX1R8Xo.
>>>
>>
>> Thanks, already a member
>>
>>
>>>
>>> Cheers,
>>> Michiel.
>>>
>>> On Sun, Aug 18, 2019 at 5:02 PM Melvin Carvalho <
>>> melvincarvalho@gmail.com> wrote:
>>>
>>>> I have written a payment server that can use arbitrarily many
>>>> authentication methods on the web.
>>>>
>>>> The outcome of that authentication is to return a verified URI.  You
>>>> could think of it as a super set of WebID, DID, user addresses and so on.
>>>>
>>>> One thing I'd like to do is have a voucher system.  So the idea with a
>>>> voucher is that it has a special code, say you email it to someone, or have
>>>> a scratch card or something.
>>>>
>>>> Then when that code is shown the back end is able to let the user spend
>>>> whatever balance it is for.  So it's a long the lines of a voucher, a
>>>> shared secret or a one time password.
>>>>
>>>> This may be similar to a bearer token, im not sure, as Im not so
>>>> familiar with those.
>>>>
>>>> My question in all this is, given that I need a URI that is linked to
>>>> the voucher.  Is there something existing I can use.  Or, is there some
>>>> sensible standard we can start experimenting with.
>>>>
>>>> The idea I had was to use the URI
>>>>
>>>> *urn:voucher:12345abcd ...*
>>>>
>>>> And if that appears in the request you know. the user can spend the
>>>> voucher, and that allows me to build an app.
>>>>
>>>> Any thoughts, ideas or previous work that can be reused here?
>>>>
>>>