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

Re: Web Payments Telecon Minutes for 2012-02-10

From: Walter <walter.stanish@gmail.com>
Date: Sun, 4 Mar 2012 11:12:25 +0700
Message-ID: <CACwuEiNQnL0NUSX8-Rb3N7LpSoRBT4bq+B1BrwzPAVSS+sTKoQ@mail.gmail.com>
To: opentransact@googlegroups.com
Cc: Web Payments <public-webpayments@w3.org>
Hi all,

Sorry I don't have time to look further through the group and
proposals yet, however I hope to catch up to where you are at
eventually and contribute further.

Right now though there's a couple of things I thought to mention that
you may find interesting or useful -- "just my two cents".

>> all the JSON-LDisms are marked as such in the main text, and the
>> JSON-LD touting entirely removed.

Another standard, JSON Schema, is relatively well developed and offers
a lot of extra functionality in addition to JSON-LD ... for example
schema specification in addition to linking. I have been using and
following its development recently. It's sort of like 'extremely
lightweight XML DTDs for JSON'. Though there are no authoring tools
right now, it's pretty lightweight and easy to get in to, though the
embedded schemas mechanism can be a bit confusing.  Anyway, if
interested do take a look: http://json-schema.org/

>> At this point, decentralized settlement protocols start making
>> sense, and the trust relations can be made the responsibility of the
>> ultimate backer. The coop co-op treats egg credits from picomoney
>> accounts the same as egg credits from attomoney accounts. A
>> distributed settlement system in my opinion should be able to handle
>> this scenario.
>
> Yes, agreed.

That's really precisely what we've been looking at with the
still-evolving proposal for a settlement system and asset (or
currency, or credit/debt measurement denomination, etc...) neutral
transaction protocol.  Over the last couple of days the the IETF
Application Area Workgroup Managers asked me to publish an outline to
their general list, which is available here:

Hopefully then we shall soon have a mailing list for the discussion of
precisely that type of solution shortly.

As an aside, by contrast from present readings it strikes me that the
W3C Web Payments effort appears to be more focused at this time
explicitly on web-based technologies and integration of simple to
deploy payments mechanisms within the general web infrastructure.
This is a different sort of problem area, in that it seems to keep a
lot of the more exotic requirements of large scale financial networks
and markets out of scope (non point-to-point communications being an
immediate example).

>> Handling means, the JSON message one gets from accessing the IRI for
>> the /Detroit coop co-op egg point/ currency must include, either
>>
>> inline or by reference to another IRI, or both, a list of one or
>> more registries trusted by the Detroit coop co-op to be legitimate
>> and trustworthy.

This sounds rather centralized.  Our approach has been to avoid
specifying any particular trust mechanism and leave it up to natural
evolution of deployment norms to create solutions that meet the needs
of early and future adopters.  Theoretically this makes greater
protocol flexibility and longevity assured.

> Therefore, it is safe to assume that if you trust B, then you can
> probably trust C. If you don't trust C, you can still perform a
> transaction with B as an intermediary, who will then eventually do the
> transaction with C (this is how Ripple works).

(In no way directly related to this discussion on web of trust) This
style of intermediary-based approach is also absolutely critical when
you want to make transactions along what we have taken to calling a
'settlement path' that necessitates the acquisition of alternative or
intermediary assets (or value-stores, currencies, debt/credit
denomination types, whatever your preferred terminology) in order to
effect settlement.  For instance, if A holds Apples and C demands
payment in carrots, B has a supply of both, the settlement path A <->
B <-> C could facilitate.

> Another form of a Web of Trust is if you trust your authority and the
> way it validates identities and amounts in financial accounts, then you
> can probably trust that funds sent to you from someone else on the
> authority will get to you. Then if there are two authorities that trust
> each other, you can probably trust that funds sent to you from someone
> else on another authority will get to you... and so on, and so on.

Again, by contrast we explicitly avoid any notion of authorities at
the protocol level.

> I think what you're discussing above is a Currency Mint and this is how
> we think it's going to work in the future:
>
> 1. The Currency Mint is responsible for creating new amounts in its
>   native currency - which are typically placed into an authority of
>   some kind.

This notion appears be based upon a false generalization: not all
assets are centrally issued, nor are they consolidated. If the goal is
to deal only with centrally issued and consolidate currencies, then
that's fine. But one should be explicit about such things. A lot of
the community currencies are not centrally issued. Economists appear
to distinguish between two kinds of asset, 'consolidated' and
'non-consolidated'. Consolidated assets are those in which the entire
distribution of an asset is mappable at a certain place ("authority")
and remains ad infinitum, for instance the case of directly held
stocks on a financial market.  Non-consolidated assets are the
inverse, for instance physical cash and coinage issued under standard
government currencies -- nobody can ever tell where they've gone.

In our transaction protocol effort, we are trying not to limit scope
at all, thus seek to cover all possibilites. However, perhaps it is
appropriate for the web payments effort to work on a more limited
scope. However, I raise the point as it is possible that this is a
de-facto property of the proposed solution under discussion and has
not been explicitly considered.  (It's also possible I've missed
something.)

Regards,
Walter Stanish
Payward, Inc.
Received on Sunday, 4 March 2012 06:23:37 UTC

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