Re: The path forward for Web Payments

Hi.
I have added my comments


On Tue, Oct 22, 2013 at 8:10 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> Hi all,
>
> Discussion on this mailing list has picked up quite a bit as of late and
> we're starting to cover a very diverse set of topics. That's great, as
> it shows that this group is bringing a great deal of different
> perspectives into the work that we do here.
>
> The diversity of discussion is not without its drawbacks. During my
> visits with the larger tech companies and organizations on this list (in
> NYC, Silicon Valley, and Bali), it's becoming apparent that the variety
> of discussion is also creating some amount of confusion over the
> direction of the Web Payments work.
>
> We're also approaching a deadline, which is the creation of the charter
> for the Web Payments group. We're going to need to propose /something/
> at the February 2014 workshop on Web Payments in Paris. We're also going
> to need to start converging on some set of proposals that we think
> should be input documents into the Web Payments Working Group.
>
> What follows is a rough proposal based on the specifications that we
> have right now that could be input documents to the Web Payments WG.
> Keep in mind that this is just a proposal and nothing is set in stone.
> The proposal is broken into 3 broad categories: specs that are almost
> done, specs that could be drafts, and specs that we need to create.
>
> Specs that are almost done
> --------------------------
>
> In general, these specs were created out of necessity for the Web
> Payments work. There are other groups that were capable of progressing
> the work faster than we could here, so in each case, a number of us from
> this group joined the other groups to progress the work there. These
> specs would not be included in the Web Payments WG charter, but are very
> relevant to the work that this group is doing.
>
> RDFa 1.1 - Technically, RDFa 1.1 is done and shipped. We needed RDFa to
> express products in a decentralized way on the Web. There could be
> improvements made to RDFa, like the addition of a @graph keyword to
> support graph signing, but it's not required for any of the specs we're
> working on right now.
>

==> start to reading document


>
> JSON-LD - This spec passed the Candidate Recommendation phase at the W3C
> last week and will most likely proceed to Proposed Recommendation soon.
> It'll be another month for voting after it enters PR, but if the votes
> are good, then it'll be an official Recommendation six weeks after it
> enters PR. We use JSON-LD to express identities, products, transactions,
> contracts, and in general, all PaySwarm messages are built on top of
> JSON-LD.
>

==> start to reading document


>
> 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.
==> what is different from JOSE format of IETF?
==> generating signature is already touched at WebCrypto API


> Specs that could be drafts
> --------------------------
>
> These specifications are being actively developed, either in this group
> or another group. The specs have an editor and implementations that are
> being actively developed. These would be in the set of work that the
> first generation Web Payments WG would work on.
>
> 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?


>
> 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?
==> if at UA side, how to protect it? by the key provided from server?
by the key generated at UA? who own the key?
==> if at Server side, I don't agree it.


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


> 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


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


>
> RDF Graph Normalization - At times, it becomes necessary to compare the
> differences between graphs, digitally sign graphs, or generate short
> identifiers for graphs via hashing algorithms. This spec outlines an
> algorithm for normalizing RDF graphs such that the previously described
> operations can be performed on the normalized graphs. This is necessary
> for the HTTP Keys spec to work as well as any of the digitally signed
> messages for the PaySwarm specs to work. The algorithm is horribly out
> of date and needs to be updated, and unfortunately, that's going to be
> very time consuming due to the complexity of the deterministic graph
> node/edge sorting algorithm.
>
> Web Identity - this specification describes how you do Know Your
> Customer using the HTTP Keys specification. It would describe how you
> read and write information to a PaySwarm identity (or any identity URL).
> It would also seamlessly integrate into Mozilla Persona such that you
> could login with Persona and then the website could request extra
> information from the identity owner such as shipping address, government
> issued ID card data, etc. It's somewhat of a competing spec to
> RequestAutocomplete, but given that it only exists in a few people's
> heads right now, it's going to take some work to get the first draft of
> it ready for consumption.
>
> 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.


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


>
> ------------------------------**------------------------------**------
>
> The general plan for this group would be to propose that the specs that
> could be drafts would be included in the work that the Web payments
> group does. A subset of the specs that we still need to create would be
> included in the charter as optional deliverables if we can find editors
> for those specifications and we get a good first draft done in the next
> 3-4 months.
>
> So, what did I miss or exclude that probably should be included? There
> is a lack of Bitcoin-related specs only because we haven't had anyone
> from the Bitcoin community step forward and propose a set of specs to
> take through W3C. The same applies for Ripple at this moment in time.
>
> Are there any specs that should be added? Should some be removed?
> Thoughts and general debate on the direction would be appreciated at
> this point. :)
>
> -- 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/ <http://blog.meritora.com/launch/>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World