- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 20 Aug 2019 15:07:55 +0200
- To: Stuart Radforth <stuart@radforth.com>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYh+33Fzm-dsgX1oBtZzOcyvCmg5f0EMyj=v1sKB8xxxLZA@mail.gmail.com>
Thanks, I've started writing up the comments in this thread. It's really just a stub / place holder for now. But I hope to flesh it out, and make it coherent, by end of this month or next. https://webvouchers.org/ On Tue, 20 Aug 2019 at 12:59, Stuart Radforth <stuart@radforth.com> wrote: > I've been implementing this in our system already so happy to share my > learnings if they help contribute to a standard. > > Firstly there needs to be a public component, this is to allow the person > owning/selling the voucher to know the voucher still contains value. The > private part is what is used to redeem and claim the voucher credit. The > private part is typically a one way retrieval process, e.g. tearing open > the packet, scratching off the silver or hologram. > > Secondly there needs to be checksums... people mistype stuff all the time. > I'm finding using a single integer number works best for computers to read > (e.g. QR code, NFC) and allow this number to be entered as mneomonics using > Bitcoin's BIP39 so people can enter say 10 words to get that integer number > to redeem the voucher. > > Thirdly the issuer needs to be included in the URN. This is because you > may have Starbucks, PayPal, CoinMode, Google, etc... could be issuing these > vouchers. Whoever is issuing the voucher needs to be named somehow. > > Fourthly the currency needs to be described. This is either USD, BTC, GBP, > starbuck points etc.. > > Finally the other key learning is there must be an optional expiry date > option as many vouchers are handled by businesses who need to reclaim lost > funds somehow and expirery solves this. > > > There are other points to consider but these seem imperative. > > i.e. the fields are > > voucher: to define it is some sort of voucher > url: where to query and get more info about the voucher. > public: very large integer value to verify amount voucher can be redeemed > for. > private: the redeeming number > destination: This is platform specific. Could be a cryptoaddress or could > be a user handle in a centralised system. > > > This gives two urns. One to check a voucher and another to redeem it > > *Check Voucher* > > URN voucher:{issuer}?public={public_number} > <http://www.acme/com/validate?public=%7Bpublic_number%7D> > > Eg. > <http://www.acme/com/validate?public=%7Bpublic_number%7D> > www.acme/com/validate?public=12345678901234567890 > <http://www.acme/com/validate?public=%7Bpublic_number%7D> > > Returns a standard structure > { > issuer:"acme", > public: 12345678901234567890 > <http://www.acme/com/validate?public=%7Bpublic_number%7D>, > is_valid: true, > currency: "bitcoin", > amount:1000000 > expires: 1238972934 (epoch time) > redeem_url : "https://www.acme.com/redeem" > remaining_uses : 1 > redeemed : false > redeemed_by : "??" > redeemed_dates : [ 123987234, 124789238 ] > } > > *Optional Redeem Voucher URN* > URN https:// > www.acme.com/redeem?private={private_number}&destination={urn_of_redeeming_url > <http://www.acme.com/redeem?private=%7Bprivate_number%7D&desk>} > > I'd expect most people would check a voucher first, get the redeem_url > from this response which would bring up a webpage where the user can see > instructions and enter their private key. The Redeem URN is mainly for > QR/NFC codes where people may scan it, basically does the same thing but > prepopulates the private value in the website. > > Kind regards, > Stuart > > -----Original Message----- > *From*: Melvin Carvalho <melvincarvalho@gmail.com > <Melvin%20Carvalho%20%3cmelvincarvalho@gmail.com%3e>> > *To*: Web Payments <public-webpayments@w3.org > <Web%20Payments%20%3cpublic-webpayments@w3.org%3e>> > *Subject*: Re: Web Payments and voucher URIs > *Date*: Tue, 20 Aug 2019 10:50:16 +0200 > > I'm encouraged by the feedback so far. > > I think I can write up more detail on web based vouchers in a mini spec, > and would be happy to collaborate, if folks here have some input. > > > On Sun, 18 Aug 2019 at 17:01, 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 Tuesday, 20 August 2019 13:08:31 UTC