Re: Web Payments and voucher URIs

Hey Melvin,
Have a looked at paymentpointers.org?
The voucher could be $vouchersforyou.com/87t88yef76df7td7wtde7twde which
translates to https://vouchersforyou.com/87t88yef76df7td7wtde7twde and is
de-referenceable.
Adrian

On Tue, 20 Aug 2019 at 11:43, Sam Mbale <smbale@gmail.com> wrote:

> Hi all
>
> This might off topic, but I thought about what Michiel highlighted:
>
>
>
>
>
> *Maybe start by base64-decoding it? But what would you see then, and how
> would that refer to a party who is willing to "cash" the voucher? 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.  *
>
>
> This could be a practical example
> New Age of Digital Asset Exchanges - Japan's Largest Gift Card Exchange
> Pioneers Blockchain Expansion
> <http://wire.mpelembe.net/pr-newswire-news-releases/?rkey=20190820EN43448&filter=9768>
>
> Tom Kanazawa, the chairman of Amaten said: *"The current system and
> technology used for gift card is completely obsolete and dates all the way
> back to the mid 90s. It has never evolved to match today's digital world.
> It still suffers from basic fundamental shortcomings and is very
> inconvenient. I believe that the gift card industry can be a perfect use
> case for blockchain. The two are a completely natural fit.**We have
> chosen to partner with the best blockchain technology providers in the
> space, aelf, because they offer the scalability, dedicated sidechains and
> smart contract modules that we very much need to build our service rapidly
> and most cost effectively. We are wholeheartedly excited for the future of
> truly digitized gift card industry."*
>
> All the best
> Sam
>
>
>
> On Mon, 19 Aug 2019 at 07:39, 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 ...'? Maybe start by base64-decoding it? But what
>> would you see then, and how would that refer to a party who is willing to
>> "cash" the voucher? 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.
>>
>> I would say there are generally two types of vouchers, relational (where
>> the issuer has some social connection to the redeemer) and anonymous (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.
>>
>> 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?
>>>
>>