W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2019

Re: Web Payments and voucher URIs

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 19 Aug 2019 08:47:49 +0200
Message-ID: <CAKaEYhJ=wFS5WJj1cGwvP6mM2yx9v-9bSNj_t0GN+_Wcj=PD+Q@mail.gmail.com>
To: Michiel de Jong <michiel@unhosted.org>
Cc: Web Payments <public-webpayments@w3.org>
On Mon, 19 Aug 2019 at 08:38, 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 ...'?
>

urns are typically not derefencable but you could write a spec to
dereference it at /.well-known/voucher/ID if you wanted to

and then put it here :
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml


> Maybe start by base64-decoding it?
>

I didnt specify an coding, tho it was perhaps implied.  This is something
it could be neat to spec.  Right now it's just a string.  Should it be
unicode I wondered?


> But what would you see then, and how would that refer to a party who is
> willing to "cash" the voucher?
>

The party cashing is orthogonal, in this case you are overloading the
identifier to be both an ID and a shared secret.  A capability URI as such,
but without the HTTP.

https://www.slideshare.net/dappelquist/capability-ur-ls-for-london-web-standards

Bitcoin does this too, but overloading IDs and public key hashes.


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

Im starting with just a simple csv or JSON which will be like the "1 star
of payments", easy enough to get up and running.


>
> I would say there are generally two types of vouchers, relational (where
> the issuer has some social connection to the redeemer) and anonymous
>

I think im starting out here with anonymous by implication.


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

Thanks, already a member


>
> 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?
>>
>
Received on Monday, 19 August 2019 06:48:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 August 2019 06:48:25 UTC