W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2014

Re: HA: VOTE: Adopt Web Commerce API as work item?

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 09 Mar 2014 15:15:06 -0400
Message-ID: <531CBDBA.1010000@digitalbazaar.com>
To: "Евгений В. Виноградов" <jonny@yamoney.ru>
CC: Web Payments <public-webpayments@w3.org>, Charles McCathie Nevile <chaals@yandex-team.ru>
On 03/08/2014 09:29 AM, Евгений В. Виноградов wrote:
> We have read a draft for Web Commerce API 1.0. Generally we agree 
> that such document must be a part of a standard. However, there are 
> some questions about Draft contents:
> 
> 1. It is mentioned in 1.2 that vendor is a seller of digital goods
> or services. However, most of the Draft is suitable for material
> goods as well. Why it is stated that only digital goods can be sold
> with this API?

It was a hold over from an old specification. The spec could apply to
physical goods just as easily as it does for digital goods. I've updated
the spec to reflect this:

https://github.com/web-payments/web-payments.org/commit/1dfa49dc2af0a7f7dcdc8348956ed0a8299dc50a

> 2. It is not clear for me from Web Commerce API docs who is 
> responsible for the Vendor's account data storage (or a set of 
> accounts data storage) - I mean the account to which the payment
> will be transferred. Is the account out of scope of this Draft?

The way the account is specified is out of scope for the spec. The
specification will have to rely on a different specification that
outlines the payment details in the payment request. For example, we
could specify the payment details like so:

https://web-payments.org/specs/source/web-commerce/#publishing-a-listing

More details about this can be found here:

https://hacks.mozilla.org/2013/04/payswarm-part-2/

Or we could use another approach, we'll have to figure out what
organizations that attend the Web Payments Workshop want to do. We have
a solution, we just need to see if organizations would want to do
something like what's described above, or they would want an option that
is easier to implement (but lacks the machine readability about the item
being sold, who is being paid, and the license information associated w/
the sale).

> (Maybe this problem can be solved with Web Identity, however, it does
> not contain an information about accounts at the moment).

Web Identity is designed to contain a "paymentProvider" field, and allow
stores to query that information about the identity during the login
process. There are no examples of this yet because we're unsure which
solution payment providers will want to settle on (Persona, OpenID
Connect, or Web Credential-based Login). We should probably include an
example in the Web Commerce API spec of a full login and purchase
round-trip.

If the solution becomes Web Credential-based login:

https://web-payments.org/specs/source/web-identity/#web-credential-based-login

A store could request an email address, street address, and payment
provider during the login process. Then, when the customer wants to make
the purchase, a purchase request is generated and sent to the customer's
payment provider (as long as the vendor trusts the particular payment
provider offered). If payment is successful, a signed digital receipt
would be returned to the vendor asserting that the payment has been made.

Does that make sense? I'm sure this response raised a few more questions. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/
Received on Sunday, 9 March 2014 19:15:38 UTC

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