Re: Web Payments and voucher URIs

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