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