Re: Web Payments and voucher URIs

If you have 'issuers', can't the issuer vouch for the voucher?

The URI finds the issuer and validates the voucher.  Then you have trust in
the system.

On Wed, Aug 21, 2019 at 4:44 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Wed, 21 Aug 2019 at 11:38, Andrew Brown <andrewbb@gmail.com> wrote:
>
>> You want me to trust an algorithm. Therefore, I am forced to learn the
>> algorithm before I can trust it.
>>
>> If I don’t study software algorithms, then I must trust IT personnel to
>> vouch for that algorithm?
>>
>
> It depends who you are.
>
> As a user you just get the voucher and spend it.  People who reset their
> passwords dont need to know how the one time code works.
>
> As an issuer in the system you probably should read the spec / algorithm
> yes, if you want to use it.
>
> It's a good point.  I should probably add a security considerations
> section, too.
>
>
>>
>>
>>
>> On 21 Aug BE 2562, at 4:22 PM, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> 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?
>>>>>>>>
>>>>>>>