Re: Web Payments and voucher URIs

Could you use a GUID?

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


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

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