Re: The path forward for Web Payments

RE: Web Payments & Web Commerce Specs "Specs out of date"

Manu or someone else, Can you explain the relationship between the Payswarm
spec and the GoodRelations spec?
http://www.heppnetz.de/ontologies/goodrelations/v1.html

I see Manu and others from this list appear also in the GoodRelations
acknowledgements
http://wiki.goodrelations-vocabulary.org/Acknowledgments

But should we assume that the Payswarm Web Payments & Web Commerce
conceptual structure ought to map to the GoodRelations class diagram?
http://www.heppnetz.de/ontologies/goodrelations/v1.html#uml
If so, should we assume that updates to the GoodRelations spec would
normally be followed by accommodation in Payswarm?
( But I see no way to register an account at
http://wiki.goodrelations-vocabulary.org/GEPs )

My specific interest is related to  "PriceSpecification" and the
"UnitPriceSpecification" as given in the GoodRelations ontology.
http://www.heppnetz.de/ontologies/goodrelations/v1.html#PriceSpecification

In particular, I wish to make the following pair of proposals, namely that:

(a) the "hasCurrency" property be adjusted to permit the selection of more
than one simultaneous currency as valid units for payment
http://www.heppnetz.de/ontologies/goodrelations/v1.html#hasCurrency  For
example, a vendor may be willing to accept USD, EUR and/or BTC in payment.

(b) the "UnitPriceSpecification" class
http://www.heppnetz.de/ontologies/goodrelations/v1.html#UnitPriceSpecificationinclude
a "hasUnitPriceIndex" property.

IF more than one currency is identified by a vendor, THEN the vendor must
also select a preferred pricing index (this could potentially just default
to the first of the options summarized below).

A vendor who choses to accept in payment and this to display prices in all
three of USD, EUR and/or BTC could choose to have the three posted prices
move through time against one of the supplied indexing options, such as:

(a) WM-Reuters forex index
http://www.wmcompany.com/wmr/Services/ClosingSpotRates/index.htm which the
major banks compile and use when they are publishing forex rates
http://www.wmcompany.com/wmr/Partners/IndexCompilers/index.htm When making
that particular choice, the vendor also must identify which central bank's
currency to use as the reference unit. That could be the national currency
of its head office or some other "vehicle" currency (However see:
http://uk.reuters.com/article/2013/10/16/uk-markets-fx-rigging-idUKBRE99F0HU20131016and
http://www.publicaffairsbooks.com/publicaffairsbooks-cgi-bin/display?book=9781610391153
and
http://www.us.penguingroup.com/nf/Book/BookDisplay/0,,9781591844495,00.html)

(b) The World Price Index
http://www.worldeconomics.com/WorldPriceIndex/WPI.efp

(c) Official Consumer Price Indices
http://data.worldbank.org/indicator/FP.CPI.TOTL.ZG
(derived from Coats' rationale: http://works.bepress.com/warren_coats/25/ )

(d) An index linked to market capitalization  http://www.world-exchanges
.org/statistics/monthly-query-tool (derived from Pringle's rationale:
http://www.themoneytrap.com/2012/11/a-five-point-reform-plan/  )

(e), (f), (g), ... etc.  (Some colleagues and I are developing an index
called the Earth Reserve Index, based on a small number of foundational
biophysical indicators  (eg, such as infrared reflectivity the Earth's
surface http://landsat.usgs.gov/best_spectral_bands_to_use.php ), weighed
according to data on the geographical distribution of transaction
currencies.


So I wish to know if the above proposal should be submitted to the
"GoodRelations Enhancement Proposals" section
http://wiki.goodrelations-vocabulary.org/GEPs or somewhere else.
(Meanwhile, I see no way to register for an account on that site. Martin,
please advise.) And is there any ongoing connection between updates at Good
Relations, and updates to Payswarmn?  If not, would my proposals need to be
made, discuss and approved/adjusted/declined in both places?

-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
http://www.projectmanagementhotel.com/projects/opman-portfolio
jpotvin@opman.ca
Mobile: 819-593-5983
LinkedIn (Google short URL): http://goo.gl/Ssp56
 <http://wiki.goodrelations-vocabulary.org/GEPs>


On Tue, Oct 22, 2013 at 7:10 AM, 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 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/>
>
>



<http://goo.gl/Ssp56>