Re: Web Payments and voucher URIs

On Wed, 21 Aug 2019 at 11:19, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Wed, 21 Aug 2019 at 09:45, Andrew Brown <andrewbb@gmail.com> wrote:
>
>> So, the core inception is a password or unlock code/key?
>>
>> Where is the password stored?
>>
>
> Yes.  You could call it a shared secret.  Or an unmissable string.
>
>
>>
>> If you say brain, what if someone finds out your password?  They would
>> walk into your identity.
>>
>
> Same like a cookie.  Only the relevant parties share the secret.
>
>
>>
>> The zero-vouch system. ‘I vouch for this and I am sovereign.’
>>
>> So, if that is the case, can you ask the issuer of the voucher to
>> validate the voucher before it is spent?
>>
>
> You could do that yes.  Using that you can extend the places where the
> voucher can be used, but the downside is that it requires more trust.
>

That should read unguessable.

Storing would simply be in a JSON file, or DB etc. it's just a string, many
solutions here.

Vouchers by nature are designed for one time use.  So think of it like a
password reset code.  They tend to expire, to prevent the threat of someone
getting the code.


>
>
>>
>>
>> On 21 Aug BE 2562, at 1:49 PM, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> 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.
>>> Adrian
>>>
>>
>> Regarding the lookup of a voucher.  I think we can register
>>
>> /.well-known/voucher/voucher_id
>>
>> For those that want to provide more info
>>
>> This would be declarative and be open ended as to the nature of the
>> voucher
>>
>> As mentioned expiry is an important field.  But I think this could also
>> be generalized.  Because once you have declarative definitions you can
>> become fully turing complete.  Smart "web" contracts if you like, can be
>> baked into a voucher, for various use cases.
>>
>> For example expiry is simply a voucher plus a time function.  (if before
>> date X, value = 100% face value) I like the thought experiment of thinking
>> of these things as programmable in a modern sense.  ie functional,
>> chainable, conditional, returning promises etc.  Doesnt have to be in the
>> spec, this can simply be an extension of the voucher definition when it
>> gets dereferenced.
>>
>>
>>>
>>> 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?
>>>>>>
>>>>>