Re: Web Payments and voucher URIs

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.


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