W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2015

Re: Markup for payable HTML resources

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 18 Nov 2015 12:32:38 +0200
Message-ID: <CA+eFz_L7yZ_qd_tCBKuw-0toQqRtHaE8rqTPBvbyR4A1=2HdjQ@mail.gmail.com>
To: Meinhard Benn <meinhard@satoshipay.io>
Cc: Web Payments CG <public-webpayments@w3.org>
Hey Meinhard,

The topic of a declarative mechanism for doing this did come up in the Web
Payments WG discussions in TPAC last month.

Currently the WG is scoped to define a standard payment request flow and
also the associated message elements for describing the supported payment
schemes and payment terms [1].

I'd consider SatoshiPay a payment scheme in this sense, although we have
started moving away from using the phrase as it has some well defined
definitions among various stakeholder groups so I like to just say payment
method or way to pay.

I don't think it would be a stretch to take the payment request message
definition and derive a good way for this to be expressed declaratively (as
opposed to a JSON object or similar that is passed to the payments API).

The current stage of this work is that we are evaluating two proposals for
how this API and messaging could be designed so I'd suggest looking at them
and seeing if you have an effective way of putting those messages in a
declarative form.

An alternative approach may be to use 402 responses when requests are made
for specific resources (like images) and use this as a trigger to kick off
the payment flow.

[1] http://www.w3.org/Payments/WG/charter-201510.html#Web_Payments_Terms

On 18 November 2015 at 01:37, Meinhard Benn <meinhard@satoshipay.io> wrote:

> Hello fellow web payment enthusiasts,
>
> I have been reading this list for a while and I'd like to introduce
> myself and ask for your opinion on an issue I'm currently trying to
> resolve.
>
> I am the founder of SatoshiPay and we are looking at making paying for
> web content as frictionless as possible for all parties involved. As our
> payment layer we chose bitcoin payment channels (a simple "smart
> contract" on the bitcoin blockchain), because of its extremely low
> transaction fees - think fractions of a cent. Our system works without
> any download or sign-up for the end user, because we ship a complete
> bitcoin wallet written in JavaScript with the website the payable
> content is on and instantly create a private key if the user doesn't
> have one yet.
>
> To make a simple integration for the content publisher or merchant as
> easy as possible we simply added a few data properties to HTML tags,
> which will be parsed by our JavaScript widget. In code it currently
> looks like this:
>
> <div class="satoshipay-content-item-text satoshipay-masked"
> data-content-url="http://will.satoshipay.eu/api/v1/article?id=4ypNl2BMe"
> data-satoshipay-id=563cc11c8c823d110025e951 data-content-length=1170
> data-price=4000></div>
> <script src="https://wallet.satoshipay.io/satoshipay.js"></script>
>
> Dump this anywhere on any website and it will just work. Your payments
> will be donated to our office coffee fund. :)
>
> Some documentation for the enriched div tag:
>
> <div
>   /* trigger class, plus design */
>     class="satoshipay-content-item-text satoshipay-masked"
>   /* content URL after payment */
>     data-content-url="http://.../article?id=4ypNl2BMe"
>   /* product ID at SatoshiPay */
>     data-satoshipay-id=563cc11c8c823d110025e951
>   /* content length (for text) */
>     data-content-length=1170
>   /* price in satoshis (0.00000001 bitcoin) */
>     data-price=4000
> >
>
> What's happening in the http://will.satoshipay.eu/ example is that after
> top-up the JS bitcoin wallet connects to the SatoshiPay server via
> WebSocket, negotiates the smart contract and moves funds to a multi-sig
> bitcoin address. With each payment the contract gets adjusted and a
> payment certificate is issued to the client by the SatoshiPay server.
> This certificate (currently a pre-shared secret) is shown by the client
> to the content server, which then ships the content. At no point
> SatoshiPay ever holds control over funds. We are merely the broker.
>
> Now, while the payments work fine, there are a few issues with the
> markup above as it's neither flexible nor consistent. So that's my where
> my question starts. My current idea is to redesign as follows:
>
> <div
>   data-sp-type="text/html"
>   data-sp-url="/paid-content/1?spCert=%s"
>   data-sp-id="563cc11c8c823d110025e951"
>   data-sp-currency="XBT"
>   data-sp-price="0.00004"
>   data-sp-length="1170"
> >
>
> Improvements:
>
>  - there is a vendor prefix
>  - different text types could be rendered and styled differently
>  - the position of the SatoshiPay payment cert in the content retrieval
>    URL can be controlled by the publisher
>  - different currencies are supported
>  - price denomination meets a standard
>
> A payable image could look like this:
>
> <img
>   data-sp-type="image/png"
>   data-sp-url="/paid-images/1?spCert=%s"
>   data-sp-id="abcdef"
>   data-sp-currency="XBT"
>   data-sp-price="0.00006"
>   height="600"
>   width="800"
> >
>
> Video/audio tags and download links would follow a similar pattern.
>
> So, I was wondering, did you spend some time on thinking about a
> standard for this already? The only W3C resource I found is a retired
> draft from 1999: http://www.w3.org/TR/Micropayment-Markup/
>
> On https://www.w3.org/community/webpayments/ I see a lot of JSON, but no
> HTML markup.
>
> Other thoughts? Are we thinking the right direction here?
>
> Cheers and thanks for listening, Meinhard Benn.
>
>
>
Received on Wednesday, 18 November 2015 10:33:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:43 UTC