- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 24 Feb 2012 22:14:04 -0500
- To: Web Payments <public-webpayments@w3.org>
Sorry for the delay... the minutes from the last call are now available
here:
http://payswarm.com/minutes/2012-02-10/
Full text of the discussion follows for archival purposes at the W3C.
---------------------------------------------------------------------
Web Payments Community Group Telecon Minutes for 2012-02-10
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2012Feb/0009.html
Topics:
1. JSON-LD Standardization Updates
2. Linked Data and Payment Technologies
3. Web Payments 1.0
Facilitator:
Manu Sporny
Scribe:
David I. Lehn, Manu Sporny
Present:
David I. Lehn, Manu Sporny, Pelle Braendgaard
Audio:
http://payswarm.com/minutes/2012-02-10/audio.ogg
David I. Lehn is scribing.
Manu Sporny: JSON-LD Standardization updates and spec split on
the agenda today. Trying to figure out focus for next few months.
Any changes or updates?
Manu Sporny: Potential call time change? 4pm EST Friday? 4pm
other days? I'll setup a poll.
Pelle Braendgaard: 12pm would be best for me.
Manu Sporny: We'll put up a poll and see what times works for
everyone.
Topic: JSON-LD Standardization Updates
Manu Sporny: Talking with w3c about standardization. Work on
JSON-LD started 2 years ago, built it for PaySwarm. Building it
in Linked JSON Commuity Group. RDF WG has JSON for RDF in its
charter. JSON-LD can be transformed to RDF, but it's primarily
meant for Web developers.
Manu Sporny: RDF WG may pick up work for JSON-LD... it is
getting stable enough for standardization, maybe in next 4-6
months we will start official standardization on it. [scribe
assist by Manu Sporny]
Topic: Linked Data and Payment Technologies
Manu Sporny: David Nicol sent some questions to the mailing
lists. Asked if or how linked data should be a part of these
standards. How does Linked Data work for payment technologies?
Manu Sporny: David had an issue with the use of JSON-LD in
payswarm... but not clear exactly what his issue was.
Manu Sporny: We may want more documentation about why linked
data and IRIs are needed in a payment standard. Melvin Carvalho,
Web Credits, has been having same issues. We should write
something up explaining why Linked Data is used in payment tech.
Pelle, any thoughts on this?
Pelle Braendgaard: No push back on the aspect of using IRIs as
identifiers... it is pretty accepted as a best practice for REST
stuff. [scribe assist by Manu Sporny]
Manu Sporny: Pelle, have you had any issues with use of linked
data in OpenTranact?
Manu Sporny is scribing.
Pelle Braendgaard: Dave Nicols largest concern is that it can be
hard to understand what is in a message - it can be derefrenced
in many different ways - this is what I understood - it could be
dangerous with novice programmers.
Pelle Braendgaard: In the XML digital signatures standard - huge
standard designed to do everything - novice programmer would
think that XML document is the signature - they would pass the
document in and the library would say the signature was okay.
Pelle Braendgaard: Except, the signature wasn't okay - big
security risk.
Pelle Braendgaard: You could imagine that there could be things
referenced elsewhere and a novice programmer would use regular
JSON library to "verify" the document.
Pelle Braendgaard: It's a legitimate security issue - bad
implementations.
Pelle Braendgaard: There are a lot of the language of Linked
Data and RDF that makes many average developers switch off.
Manu Sporny: Yes, it's certainly an issue.
Pelle Braendgaard: All of a sudden you can't understand
everything in the document - they're all aesthetic concerns.
Pelle Braendgaard: The normal workflow for Ruby and JavaScript
is that when you parse JSON, the fields become symbols - having
namespace or @ signs in there make it weird for a Ruby
programmer.
Pelle Braendgaard: Dot-notation is used more than dictionary
notation.
David I. Lehn: Yes, we've run into that issue as well. The
dot-notation one - there are issues.
Pelle Braendgaard: I think David Nicol's security concern is a
bigger issue.
Manu Sporny: Yeah, we've tried very hard to try to make JSON-LD
simple... avoid the nasty Semantic Web terminology for the most
part. Unfortunately, this is lost on people that look at the
JSON-LD spec for the first time. It's a balancing act - difficult
to find something that wouldn't conflict w/ existing JSON, would
merge with it easily, but also have something simple and
expressive. I think we need to explain Linked Data a bit better.
Manu Sporny: It's difficult to take a novice developer from JSON
to JSON-LD... in the end, our hope is that the data structures
will look very familiar to JSON developers. Take colons out of
the names? Instead of 'foaf:homepage', we use 'homepage'. That
was your preference, right Pelle? The difficult part in the Web
Commerce spec - decentralized assets/listings - difficult to
solve the problem w/o using Linked Data. We tried to solve the
problem w/ regular JSON - it was a mess. We speak from experience
- we tried regular JSON... it was a mess. David Nicol's issue was
mostly with messaging - "show me why Linked Data is beneficial".
Maybe we start at URLs and go into JSON-LD aspect of it.
Pelle Braendgaard: Some suggestions - for example, rdfs:comment
- com:amount, com:currency - I don't think you need to specify
the namespace.
Pelle Braendgaard: I think there is a middle-way - of course use
URIs/IRIs - URL / URI - people don't know what an IRI is
(culturally difficult)
Manu Sporny: Yes, Internationalized languages was a big concern
at W3C - UTF-8 came out as a result, IRI came out as a result.
Pelle Braendgaard: I think we should use URL - it's
colloquial... when we explain it to people. Use IRI in the spec.
Pelle Braendgaard: Part of the whole Linked Data movement is to
have strong definitions. In everyday speech, technical
preciseness confuses people.
Pelle Braendgaard: Going back to receipts - transfers / receipts
- yes, use references - you could have an object encapsulated,
right? Isn't it a security risk to have to go out and derefernce
an IRI?
Manu Sporny: Oh, right - we have tried to write the application
so that dereferencing rarely ever needs to happen.
David I. Lehn: Processors might need to dereference the context.
Manu Sporny: Yes, but in most cases, they won't becaue the
context will be hard coded or cached. It is a security risk...
but a manageable one (look at Web browsers - they have to
dereference stuff all the time).
Pelle Braendgaard: That's where there may be a slight danger,
here. We could have JSON-LD that is dereferenced. Novice
programmers may have issues with all of this... using libraries
without understanding everything that is going on. A false sense
of security. We should protect against that.
Manu Sporny: Yes, I agree - security issues we need to look out
for. Addressing each is going to be slightly different. We should
narrow the envelope of attack.
Pelle Braendgaard: Most of functionality should be useful w/o
JSON-LD library. You should be able to use just regular JSON.
Manu Sporny: The Authorities are the ones that have to check the
JSON-LD objects. The digital signatures will be able to be
handled via JSON-LD libraries... but I think those libraries will
be required for this type of system. Same argument for OAuth -
use the libraries, don't try to roll your own. This isn't a
simple problem - it's not going to be easy to address.
Manu Sporny: The security aspect of this is not going to be
easy. I'll try to look at what David Nicol is saying - we'll try
to update the spec language to give a gentler introduction to
Linked Data. Big mistake of Linked Data is not making the
concepts very accessible to people.
Manu Sporny: Maybe the solution to this is to use colloquial
explanations when writing blog posts and tutorials and use the
technically correct term in the spec. Writing specs is different
- we have to use technically correct definition because they are
W3C specs... so, we will have to use IRI there... URL when
discussing w/ regular web developer folks.
Pelle Braendgaard: Yes, we should use colloquial terms when
communicating to Web developers, use specific terms in spec.
Pelle Braendgaard: We should have a bit in the spec that
outlines briefly what an IRI is, for beginner readers.
Manu Sporny: We've tried to do that in the spec - we go into
terminology fairly deeply - we should do the same for the
PaySwarm specs.
Manu Sporny: Anything else on this topic before we move on?
Topic: Web Payments 1.0
David I. Lehn is scribing.
Manu Sporny: Over last two weeks we took Pelle's criticisms to
heart and split the spec up into multiple documents.
Manu Sporny: Spec split into four major components, along the
lines that Pelle outlined. Didn't think spec split was going to
lead to as many arguments as it did.
Manu Sporny: Web Keys 1.0 - public key infrastructure for the
Web.
Manu Sporny: Web Payments 1.0 - with basic transaction support,
decentralized settlement algorithm, and data portability.
Manu Sporny: Web Commerce 1.0 - how to sell digital content on
the web - assets, listings, contracts, receipts, etc.
Manu Sporny: Payment Intents 1.0 - how to do crowd-funding, etc.
Manu Sporny: The specs are built on top of each other. They can
be developed and standardized on their own timeframes - Web Keys,
Web Payments lead... Web Commerce next... then Payment Intents.
Pelle Braendgaard: Congratulations on the split, it is the right
thing to do.
Manu Sporny: Thank you. I think we started out with fairly rocky
arguments - glad you stuck it out Pelle and kept fighting for it.
I think we're all better off for it. I hope it's a clear sign
that we do listen and want what's best for the Web, payments and
these specs. Thanks for arguing for that change... I don't think
we would have made the change this soon had you not argued as
strongly as you did.
Manu Sporny: The Web Payments 1.0 spec:
http://payswarm.com/specs/ED/web-payments/2012-01-30/
Manu Sporny: Section 4.2 specifies how Transactions happen -
basic transfer of money from one place to the next. You take a
JSON transaction and HTTP POST it to a transaction endpoint to
move money. Pretty simple and straight forward. The decentralized
settlement process is also there - if source and destination
account exist on different authorities - how do you make sure
electronic bookkeeping stays in sync. This is about ensuring that
the decentralized system does not require human intervention.
Manu Sporny: How do you make the transaction atomic between
decentralized systems. The algorithm has to be resistant to
failure - has to be atomic. The algorithm outlined is a
decentralized settlement algorithm. Any questions?
Manu Sporny is scribing.
Pelle Braendgaard: I think eventually, Decentralized Settlement
would make more sense in a separate specification. It's an
important aspect, there are a lot of different ways it can be
done. Does PaySwarm require decentralized settlement for the base
level spec?
Manu Sporny: Right now, yes, decentralized settlement is
required. The concern is that a large payment processor would
implement the spec such that they don't interoperate with other
payment providers. Counter-argument is that they wouldn't
implement PaySwarm if they didn't want to interoperate. The
counter-counter argument to that is that if PaySwarm is
successful, implementers would only implement things that would
benefit them and not the parts that would create competition for
them. By and large, many corporations believe that
interoperability in their core business leads to stronger
competition and corporations don't like that. They tend to favor
monopolies rather than even playing fields. The short answer is:
Yes, decentralized settlement is required. We may end up being
out-voted at W3C - Google, Amazon, PayPal may feel that they
don't want decentralized settlement in there. Make sense?
Pelle Braendgaard: My main two objections to having the
decentralized settlement algorithm in there: 1) There has to be
some trust relationship between authorities (this is really
important - it's a complicated issue)
Pelle Braendgaard: I think Melvin's Web Credits shows how to
build a Web of Trust, good start to solving this issue. However,
that is a separate issue to doing just a simple payment. This is
why we're indifferent to the types of assets we're transferring
in OpenTransact. It limits us to national currencies or one or
two alternative currencies - there has to be a trust
infrastructure for each alternative currency.
Pelle Braendgaard: So, 2) It limits us to national currencies or
one or two alternative currencies.
Pelle Braendgaard: For example - w/ OpenTransact - you could use
it to transfer Domains, you could use it for Shares, you could
use it for non-traditional money. It could be a local community
currency - it wouldn't make any sense to have a decentralized
settlement process.
Pelle Braendgaard: So, for example - Coconut Grove Currency -
whole idea is to be local.
Pelle Braendgaard: If you require Decentralized Settlement, it
limits it because (I understand the reasons - we don't want a
PayPal to just sit and operate as an island) - then we need to
make that a separate... have people opt-in.
Manu Sporny: Not enough language in the spec to get this right
now - we do support alternative currencies - you can use any ISO
currency code, or you can use an IRI as the currency. If you use
an IRI, that IRI can mint new units of currency. If one Authority
wants to use the IRI currency, the other Authority doesn't have
to accept it. The decentralized algorithm doesn't always have to
succeed. You would expect it to always succeed for USD, Euro,
Yuan, etc. However, you wouldn't always expect it to work for
alternative currencies. Maybe it /would/ work for alternative
currencies... maybe local currencies stay local if they have a
flag. What I'm saying is that there is no requirement that every
authority has to accept every currency. You're right - there are
some currencies where it doesn't make sense for it to be
decentralized.
Manu Sporny: We're out of time for today. I'll send out a link
to a poll to decide on a time. We'll try to clean up language in
Web Keys and Web Payments specs. Any other comments before we get
off of the phone?
Pelle Braendgaard: One quick comment - are you really married to
the "source" and "destination" parameter names?
Manu Sporny: We like them, but not married to them. Everything
is fairly malleable during the demo period, once we launch a
commercial system, we would really not like to change those. One
of the nice things about JSON-LD is that you don't always have to
use 'source' and 'destination', you could use 'to' and 'from'.
Pelle Braendgaard: What about "to" and "from"? Make it more
human. It's shorter. Let's try to keep these things simple. For
example: memo vs. note. We should try to map between OpenTransact
and PaySwarm.
Pelle Braendgaard: We could create some level of compatibility
between Web Payments and OpenTransact.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Saturday, 25 February 2012 03:14:37 UTC