Re: Markup for payable HTML resources

The API proposals are here:

https://github.com/WICG/paymentrequest/
https://github.com/WICG/web-payments-browser-api

There are also these two proposals from the CG

https://github.com/web-payments/web-payments-messaging
https://github.com/web-payments/web-payments-http-api
<https://github.com/web-payments/web-payments-messaging>

On 18 November 2015 at 12:32, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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