Re: Web Payments and voucher URIs

On Tue, 20 Aug 2019 at 15:12, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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

Thanks for the pointer.  I possibly had seen an earlier version of this,
but thanks for the refresher.

I'll add this as a reference, and read through it more carefully.  But at
first blush, the idea of using the /.well-known/ pattern to deference, in
some cases, is appealing.  Because then you can build in a discovery
mechanism.

I think I'd like to model vouchers as a URI, at least in one of its forms,
rather than a string such as "$identifer", which is not a URI.  But there's
no reason the two cant be linked together, somehow.

It was helpful to look at this, and it's made is clearer the case where a
voucher id and server act as a pair which could be sent to someone, say, in
an email.  I suppose a very typical pattern along these lines is the
password reset.

Thanks again for the pointer, very much interested in existing work.

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