Re: Web Payments and voucher URIs

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