Re: The path forward for Web Payments

On 10/27/2013 09:15 PM, Mountie Lee wrote:
> HTTP Signatures - This spec is waiting on the examples to be updated.
> I just haven't found the time to do it and publish it via IETF. The
> technical stuff in the spec has been done for some time, and we have
> two implementations. HTTP Signatures are used over HTTPS for
> programmatic access to PaySwarm payment processor REST APIs.
>
> ==> please inform the link for HTTP SIgnatures.

https://payswarm.com/specs/source/http-signatures

> ==> what is different from JOSE format of IETF?

The complete analysis of the differences are outlined here:

http://manu.sporny.org/2013/sm-vs-jose/

> ==> generating signature is already touched at WebCrypto API

Could you provide a link? Creating a digital signature for a JSON blob
containing Linked Data is not covered by the WebCrypto API, and is what
is required in order to do Web payments correctly.

> HTTP Keys - a secure and verifiable messaging mechanism built using
> Linked Data principles to produce a distributed Public Key
> Infrastructure for the Web. We need to update this spec to match
> current implementations, but a good enough chunk of it is there and
> could easily become a first draft of an official W3C WG.
>
> ==> what is different from JOSE + WebCrypto API combination?

The differences are outlined here:

http://manu.sporny.org/2013/sm-vs-jose/

> RequestAutocomplete - a mechanism of auto-filling form data with
> things like credit card information, address information, etc. Google
> is probably not going to have much of an issue putting this through
> W3C via Web Apps, but the Web Payments group could be another venue
> that they could use to publish the specification.
>
> ==> where the sensitive information stored?

In the browser.

> ==> if at UA side, how to protect it? by the key provided from
> server? by the key generated at UA? who own the key?

There is no PKI as far as I'm aware in Request Autocomplete. The
protection mechanism is up to the browser implementor.

> ==> if at Server side, I don't agree it.

Yes, that would be awful. Although, I think Apple does this for some of
their products (storing things that should be client-only in their cloud).

> Web Payments - the base layer of the PaySwarm architecture; enables
> the creation of a monetary transaction between two participants on
> the Web. Again, the spec is badly out of date, but it wouldn't take
> that much work to bring it up to date with the current implementation
> and produce a first draft for an official W3C WG.
>
> ==>  I failed to catch concept of PaySwarm by reviewing web site
> draftly. it seams showing use cases. ==> could you share the link for
> more technical details?

Yes, read the first three links about PaySwarm here:

https://payswarm.com/intro

> Web Commerce - the electronic commerce portion of the PaySwarm
> architecture; enabling the decentralized listing of assets for sale
> and the transaction of those assets resulting in a digitally
> verifiable receipt between the buyer and the vendor. Same as above.
> Specs out of date, needs to be updated based on current
> implementation.
>
> ==> please inform the link for Web Commerce

https://payswarm.com/specs/source/web-commerce/


> Specs that we need to create ----------------------------
>
> Payment Intents - the parameterized transactions layer of the
> PaySwarm architecture; enables decentralized crowd-funding for
> innovative initiatives and projects. We need to re-think this
> specification. We do want to support crowdfunding as a first-class
> function of a Web Payments solution. However, with the advent of
> Ripple, the way that we go about that might be different than when we
> wrote this specification.
>
> ==> can focus after understanding PaySwarm architecture.

Here's the link for the current spec:

https://payswarm.com/specs/source/payment-intents/

> Secure Frame - This is the direction that the MozPay specification
> seems to be taking. This approach was suggested by Kumar and would be
> used to create a whitelisted payments/secure exchange dialogue that
> would be very difficult to spoof by attackers. This dialogue could be
> used by payments companies to implement proprietary as well as open
> buyflows.
>
>
> ==> have interest for it. ==> the secure frame should be sandboxed
> even from internal attack when OS was compromised.

How do you sandbox software that is running on a compromised operating
system without specialized hardware? You seem to be asking for a feature
that's logically impossible to implement.

> External Payment Initiation - We've been talking with a few
> organizations that do payments that would like a way to initiate a
> payment within the browser and then hand the transaction execution
> off to an external application. The general concept needs to be
> worked out, and we need to find editors for this specification. If we
> can get something together for this in the next 4 months, we stand a
> good chance at getting a first draft ready before the Web Payments WG
> is chartered.
>
> ==> the concept is similar to my suggestion (ECIS). ==> If we have
> more wider view, it can be deployed to more areas (payment,
> identifying, delivery, currency exchange...)

Could you elaborate a bit more on this? Your ECIS proposal has a large
amount of overlap with the work we're doing here, so there is plenty of
opportunity for collaboration here. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Monday, 4 November 2013 03:11:58 UTC