- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 24 Jul 2013 14:19:59 -0400
- To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for supporting scribing duties. The minutes for
this week's Web Payments telecon are now available here:
https://payswarm.com/minutes/2013-07-24/
Full text of the discussion follows for archival purposes at the W3C.
Audio of the meeting is available as well (link provided below).
--------------
Web Payments Community Group Telecon Minutes for 2013-07-24
Agenda:
http://lists.w3.org/Archives/Public/public-webpayments/2013Jul/0019.html
Topics:
1. Introduction - David Bialer
2. GSoC Student Progress
3. Analysis of MozPay API message format
4. Unnecessarily Cryptic JSON Keys
5. iss and APPLICATION_KEY
6. Audience
7. Issued At and Expiration Time
8. The Request
9. Request ID
10. Price Point
Chair:
Manu Sporny
Scribe:
Manu Sporny
Present:
Manu Sporny, David Bialer, Kumar McMillan, Andrei Oprea,
Travis Choma, Dave Longley, David I. Lehn
Audio:
http://payswarm.com/minutes/2013-07-24/audio.ogg
Manu Sporny is scribing.
Manu Sporny: Any updates or changes to the Agenda?
Manu Sporny: we have a new participant, David Bialer [scribe
assist by Dave Longley]
Topic: Introduction - David Bialer
Manu Sporny: can you give us a quick intro? [scribe assist by
Dave Longley]
David Bialer: Product manager for Firefox marketplace - work
with Kumar and Travis. I'm very product focused. Been reading the
notes of this group for a while
David Bialer: My interest - Payments 2.0, looking at things that
we'd like to be doing over the next year in payments.
David Bialer: We're doing operator billing today, but don't
think that's necessarily the way to go in the future. After doing
integrations, we've noticed lots of warts/bumps. MozPay, future
spec, would like to see some things that can deal with the
realities of how systems work today. Especially in the
international world of currency exchange and emerging markets.
Manu Sporny: you're in the right place, this group is all about
finding solutions for those areas and writing specs for them
[scribe assist by Dave Longley]
Kumar McMillan: To follow up, as developers we're down in the
weeds more than David - he has an idea of what we're doing
long-term with payments.
Topic: GSoC Student Progress
Manu Sporny: next up is andrei's progress on the open
marketplace he's building using payswarm [scribe assist by Dave
Longley]
Andrei Oprea: I had issues w/ the asset hash not generating, the
date format was changed when saving in the database, I've fixed
that. Dave Longley helped me out w/ the payments stuff. I can now
do a payment for the web app.
Manu Sporny: Very good progress, Andrei. So you have publishing
an asset, publishing a listing, digitally signing both, and
performing a purchase working now.
Andrei Oprea: Yes, I'm doing the purchase via a pop-up. Next,
I'd like to make purchasing available via the payswarm module so
that you don't have to navigate away from the website
(budget-based purchases). Having issues w/ vendor and accounts
that's listing the item for sale. The purchase was unsuccessful,
had to switch to the pop-up mechanism.
Manu Sporny: You're making good progress, keep up the great
work. :)
Manu Sporny: Keep working on IRC with Dave Longley on that if
you need help [scribe assist by Dave Longley]
Topic: Analysis of MozPay API message format
Manu Sporny: i did a really quick analysis on the message format
for what's in the API spec, i started looking at JWT and the
whole JOSE stack of specs and decided that it's not really
helpful to talk about those if we're not aligned on what we want
(the types of information) in the message blob [scribe assist by
Dave Longley]
Manu Sporny: in the link in IRC i compare and contrast against
payswarm messages [scribe assist by Dave Longley]
Manu Sporny: soon i'll compare and contrast against between JWT
and JSON-LD and talk about advantages/drawbacks for both, and we
can talk about whether we should be using JWT or JSON-LD for the
mozPay use cases, etc. [scribe assist by Dave Longley]
Manu Sporny: i saw kumar responded a bit and we'll go through
each point [scribe assist by Dave Longley]
Kumar McMillan: http://manu.sporny.org/2013/mozpay-analysis/
Manu Sporny: so we'll go through the blog post top down ...
there's just a quick intro to start [scribe assist by Dave
Longley]
Manu Sporny: so we've got a purchase request to buy a magical
unicorn [scribe assist by Dave Longley]
Manu Sporny: scrolling down a bit to the first subheading
"Unnecessarily Cryptic JSON Keys" [scribe assist by Dave Longley]
Topic: Unnecessarily Cryptic JSON Keys
Manu Sporny: so this first issue is about a side effect of the
JOSE stack, JOSE uses 3-letter IDs for all of the things that are
JOSE and JWT-specific [scribe assist by Dave Longley]
Manu Sporny: maybe kumar knows more about their decision process
here, but to me it seems like a 1980's protocol design to save
bits on the wire and it just makes the messages less human
readable and is unnecessary [scribe assist by Dave Longley]
Manu Sporny: you end up having to read much more about things to
figure out what's going on instead of getting some idea of what's
going on and what keys are about ... payswarm keys tend to spell
things out to avoid that problem [scribe assist by Dave Longley]
Manu Sporny: if we use JWT and JOSE we can't change this ...
going with payswarm/JSON-LD would allow us to do that [scribe
assist by Dave Longley]
Kumar McMillan: Yeah, agree with all that mostly. It makes our
code/docs pretty complicated when we have to document all of
these things. We did it because it was part of the spec. It would
be great to have more readable identifiers. The main things that
I think JWT buys us, that we need to retain, is the issued at
time and expiration time to prevent against replay attacks.
Kumar McMillan: Seems like we can do that until validFrom and
validUntil. Issuer is important because it's the key we validate
against.
Kumar McMillan: audience isn't really all that important.
Manu Sporny: payswarm has a concept of an issuer, payswarm has a
key or hmac that a digital signature is created from, that key
has a URL which identifies it, the key is owned by an identity
which also has a URL [scribe assist by Dave Longley]
Manu Sporny: there's a half-way point where we could just use a
URL for the issuer ... we can get to this in a bit [scribe assist
by Dave Longley]
Manu Sporny: this issue is about keys payswarm specifically
tries to use human readable keys, it was a design decision to
make this as human readable and friendly as possible [scribe
assist by Dave Longley]
Manu Sporny: but there's agreement here so we can move on
[scribe assist by Dave Longley]
Topic: iss and APPLICATION_KEY
Manu Sporny: it wasn't clear to me what the APPLICATION_KEY was
or what format it's in, kumar can you describe it? [scribe assist
by Dave Longley]
Kumar McMillan: Yeah, application key is some sort of public key
or ID, some unique string that is unique across all merchants in
the firefox marketplace. It's pretty much randomly generated.
Developers will need to put it in their code, similar to how
you'd use an amazon identifier and secret. Moving it to a URL
sounds fine.
Kumar McMillan: Right now, we have hosted apps, apps can do
payments. An app doesn't necessarily have a hosted domain. It
could be a packaged app that's not hosted. It may not make sense
to put a URL on it.
Kumar McMillan: We could move it to a URL, definitely doable.
There are things we're doing because we didn't try to make
everything decentralized. Wasn't a need to use a URL, but I think
we should add as much as we can to make things decentralized.
URLs for lots of stuff is a good idea.
Travis Choma: what would the URL point to? [scribe assist by
Dave Longley]
Manu Sporny: if we're talking about the person that owns the
asset being sold, it would point to a description of that
entity... so it could be sony music, the person that created the
asset, the marketplace/whatever ... it depends on what the issuer
does [scribe assist by Dave Longley]
Manu Sporny: it's still cloudy to me what the issuer does
[scribe assist by Dave Longley]
Kumar McMillan: Right now an issuer can sell products inside the
app. They use that key to issue JWTs. The JWT is currently only a
purchase for a single product. The issuer is a merchant and they
can create as many products as they want, and they can sell
anything. JWT is just asking for a price and exchanging goods.
It's really abstract in that sense.
Manu Sporny: so that's almost equivalent to an assetProvider in
payswarm [scribe assist by Dave Longley]
Manu Sporny: For example, this is an identifier for my identity
on the Development PaySwarm Authority:
https://dev.payswarm.com/i/manu
Manu Sporny: you can get the public keys associated with that
identity, any public financial accounts, etc. a whole bunch of
information about that identity [scribe assist by Dave Longley]
Manu Sporny: in payswarm we make a distinction between the
vendor and the asset [scribe assist by Dave Longley]
Dave Longley: In PaySwarm, we have a distinction between asset
provider and vendor, often they're the same, but they don't need
to be.
Dave Longley: In marketplace cases, they tend to be the same
thing. But PaySwarm supports wider set of use cases.
David Bialer: I think we care who the original creator is, it's
about the merchant in this case.
Kumar McMillan: yeah, in our case, the asset provider is almost
always the vendor in our case.
Manu Sporny: that is what we were expecting, one of the use
cases we try to support in payswarm is where a company like
mozilla is selling apps on behalf of someone else [scribe assist
by Dave Longley]
Manu Sporny: where you don't want to deal with all of the
decentralized aspects of what's going on, you just want to deal
with putting up assets and receiving payments [scribe assist by
Dave Longley]
Manu Sporny: the use case where vendors and assets are different
came from the music industry where there are people interested in
saying "here's the newest rihanna album, you (anyone) can sell
this on the web so long as we get 70% of the profits" [scribe
assist by Dave Longley]
Manu Sporny: sony could publish that asset and a blogger could
come along and sell that on their blog [scribe assist by Dave
Longley]
Manu Sporny: so the blogger would add their own markup [scribe
assist by Dave Longley]
Manu Sporny: so that's an example of a company being able to
publish assets so they can be sold anywhere [scribe assist by
Dave Longley]
Manu Sporny: it's kind of a decentralized affiliate model
[scribe assist by Dave Longley]
Manu Sporny: so it sounds like we can use URLs and everything
would work out well for the mozilla marketplace [scribe assist by
Dave Longley]
Kumar McMillan: Yeah, using URLs is fine... today, we're
interested in both scenarios. Merchant selling product (in-app
payment), but marketplace does already sell apps on behalfs of
other merchants. This has made things a bit tricky. In our case,
who is the issuer? Is it the marketplace, or is it the app? We
settled on making it the marketplace. That doesn't always make
sense. There is edge-case code to see if you are a firefox
marketplace. Firefox marketplace is selling this, it's on behalf
of this developer -maybe we need to check the key of the
developer and not the marketplace.
Kumar McMillan: For us, for security, one issuer for all of
marketplace.
Dave Longley: What happens in PaySwarm, when you specify the
people being paid, you specify URL to financial account of person
being paid. It's very clear where funds are going in PaySwarm.
Funds are not going to just marketplace, but to the app owner.
Kumar McMillan: Yeah, that's another thing that's really
beneficial, nothing in the system that publicly specifies how
someone is getting paid. If someone wants to sell something in
Marketplace, if they want to sell it through some other
marketplace that supports open web protocols, they have to fill
in all their info again.
Dave Longley: Yeah, with payswarm they can just avoid that. THey
just need to publish the asset, they can say restrict sale of
asset through certain number of marketplace places or all
marketplaces.
David Bialer: Does the owner of the asset issue the merchant
keys?
Dave Longley: If you're publishing the asset your self, you
publish your own key and publish your asset. URL to the key is
inside the asset, you can check the signature like that. you can
also have the Marketplace act as a delegate. The marketplace
provides the key.
Manu Sporny: one of the primary design goals behind payswarm was
to get rid of the need to login to a site to buy something and
the need to log into an affiliate site to have things be resold
there [scribe assist by Dave Longley]
Dave Longley: Right, so you give people a link and then they can
put that link in the listing they create and sign it. You just
give people a listing URL to buy something.
Kumar McMillan: so how does the money get around? [scribe assist
by Dave Longley]
Manu Sporny: so in payswarm, there is an asset (description for
the thing being sold), and then there's the listing which
indicates the asset being sold the license, the payees, etc --
everything about the purchase [scribe assist by Dave Longley]
Manu Sporny: if i were creating an asset i'd put a payee with my
account in it with a restriction of "i want a $1" [scribe assist
by Dave Longley]
Kumar McMillan: that makes sense, how does the money actually
move? [scribe assist by Dave Longley]
Manu Sporny: if you're a payswarm authority you must be able to
send money to from PAs [scribe assist by Dave Longley]
Manu Sporny: PAs are like a big book keeping operation, similar
to what banks do [scribe assist by Dave Longley]
Manu Sporny: my PA might do direct deposit [missed some details]
[scribe assist by Dave Longley]
David Bialer: Are there any guarantees in that system? Is there
a guarantee that's negotiated?
Manu Sporny: Yes, there are gurantees between PAs to move money.
PAs must have legal agreements with one another, money moves from
one PA (buyer) to another (vendor and asset provider). Actual
money moving between bank accounts is out of scope for the
PaySwarm protocol, but it's usually the PaySwarm authorities that
do the final move of the money into your bank account via direct
deposit, checks, etc. [scribe assist by Dave Longley]
Manu Sporny: For example, people that you list for payment in
the asset probably all understand that you must support Bitcoin,
for instance, if a listing comes in and someone doesn't support
bitcoin, the transaction will fail because the PA doesn't support
bitcoin. [scribe assist by Dave Longley]
Dave Longley: Some of the discoverable information about the
financial accounts is the type of currency they use. When you put
payees in an asset or listing, you can state the currency
associated with an financial account.
Dave Longley: So, you can find out what currency is expected
from the listing immediately, so you can make sure the right
thing happens.
Dave Longley: The decentralized payswarm authority stuff happens
- the PA that performs the purchase is whatever PA that the buyer
is doing business with. The buyer PA initiates and deals w/ the
purchase, then that PA communicates the payment to the seller's
PA.
Dave Longley: There have to be legal agreements between PAs to
ensure funds move around appropriately.
Manu Sporny: one of the things we're talking about right now is
a block chain to help mitigate the legal barriers between PAs
[scribe assist by Dave Longley]
Manu Sporny: to give some background, there's an organization
called SWIFT that makes sure there's enough money between PAs,
other assurances, that banks must be part of ... we're trying to
create something decentralized and similar that would use a
blockchain that might be able to help alleviate some needs for
certain legal agreements between PAs. [scribe assist by Dave
Longley]
Manu Sporny: This would enable smaller PAs into the market.
We're very concerned about big financial institutions and
companies locking smaller PAs out of the market by demanding
minimum account balances of hundreds of millions of dollars, for
instance. [scribe assist by Dave Longley]
Manu Sporny: we were talking about issuer and application key
and the consensus is that we should be able to use a URL for
this, so that's good. [scribe assist by Dave Longley]
Topic: Audience
Manu Sporny: kumar, i think you said audience is only used right
now to check for a mismatch in the string and if so, the purchase
is rejected [scribe assist by Dave Longley]
Kumar McMillan: Audience isn't really all that useful. If some
merchant sends a JSON Web Token, we reject it if the audience is
different. That check isn't really that useful. If there are
multiple receivers of JWTs, maybe it would be useful where
someone can intercept JWTs?
Kumar McMillan: That may have been the original intent for
audience, don't know for sure.
Manu Sporny: payswarm doesn't specify an audience ... if you
want to restrict the people that can sell an asset you put that
in the listingRestrictions in the asset [scribe assist by Dave
Longley]
Manu Sporny: you could say only person X and the mozilla
marketplace can resell my asset [scribe assist by Dave Longley]
Topic: Issued At and Expiration Time
Manu Sporny: MozPay API uses seconds since Jan 1st, 1970 for
this value. PaySwarm currently uses human-readable dates and
times - 2013-11-05T13:15:30Z
Manu Sporny: keys aren't easy to read, we have "validFrom" and
"validUntil" in payswarm, we also make the encoded time string
more human readable [scribe assist by Dave Longley]
Manu Sporny: instead of number of seconds since epoc (1970),
which is unreadable [scribe assist by Dave Longley]
Kumar McMillan: Making this more readable makes more sense.
Dates and times are tricky because of time zones. Issued At and
Expires is always a universal timestamp. Might make sense if it's
a readable timestamp to make it in universal time?
Dave Longley: I think we've implemented UTC, let's just do it
that way.
Topic: The Request
Manu Sporny: yes, general agreement to use UTC, but human
readable strings [scribe assist by Dave Longley]
Manu Sporny: it seems like the request in the mozPay API is
equivalent to the asset description in the payswarm protocol
[scribe assist by Dave Longley]
Manu Sporny: basically it describes the item that is being
transacted [scribe assist by Dave Longley]
Manu Sporny: is that right or is it something else? [scribe
assist by Dave Longley]
Kumar McMillan: I think for how we're using it so far, you could
replace "request" with "product". Historically, we were trying to
keep it on par with the Google Wallet spec. Maybe it's because it
might always be a product for sale, maybe it would be a refund.
Either way, I think it makes more sense to think of it as a
product with a price a name and description.
Manu Sporny: ok, if we think of it like that then it aligns 1:1
with payswarm [scribe assist by Dave Longley]
Topic: Request ID
Manu Sporny: we use URLs in payswarm so you can discover more
about the item being sold so there's machine readable data being
at the URL [scribe assist by Dave Longley]
Manu Sporny: the nice thing about having the URL is that people
can also do linked data type reviews so you can say: "I'm talking
about this URL and it should get 3/5 stars" and submit that in a
decentralized way then someone like google can come along and
aggregate that stuff from the web [scribe assist by Dave Longley]
Manu Sporny: having a URL allows talking about something using
linked data in a decentralized way possible [scribe assist by
Dave Longley]
Kumar McMillan: A URL sounds like a better idea for this. It
allows for discovery of assets. When an app sells an in-app
product in a game, it would be great to expose that. Some
merchants might not want to expose it. As far as the idea is used
by us - it's not really, reserved for the merchant. The merchant
can have an ID and link it to their product ID.
Kumar McMillan: Making it a URL makes a lot of sense.
Dave Longley: We have two things in PaySwarm - a URL that
uniquely identifies the asset. Merchants can use a referenceID, a
local identifier private to them, that they can put an ID on it
that allows them to resell the same asset twice.
Dave Longley: You can increment the reference ID or change it to
sell the same asset twice. We have both ideas in PaySwarm.
Kumar McMillan: One thing that might be good to keep in mind is
... I think it would be nice... to support the case where an app
is completely offline. It sells products that it's not hosting on
any URL. It would make it simpler for developers. The solution
might be that someone like Firefox Marketplace might provide all
of the URLs. It makes it easy, they don't have to install the
website.
David Bialer: I think all of these URLs makes things less
secure?
David I. Lehn: We have hashes for all of these assets, you can
package all of this stuff up ... you can work with this stuff
offline.
Dave Longley: Mozilla could easily generate URls for people that
want to have apps w/ no website.
Manu Sporny: mozilla could easily provide a listing service or
just generate URLs for assets, we provide this service:
http://listings.dev.payswarm.com/ [scribe assist by Dave Longley]
Manu Sporny: Another option is to do something like this, which
is also valid - urn:uuid:ce070d99-9260-4d13-92bf-57e92cd0ab06 -
so merchants could still use UUIDs if they wanted to.
Manu Sporny: you could also use urns for true offline use cases
[scribe assist by Dave Longley]
Manu Sporny: another related offline thing is budgets ... so a
customer can set a budget for a vendor and then that vendor can
keep track of what the customer buys offline and then charge the
user all at once using the budget they've pre-authorized at a
later time [scribe assist by Dave Longley]
Topic: Price Point
Manu Sporny: Kumar, I know you were interested in a PaySwarm
example for pricing, here's how we encode prices in PaySwarm: {
"amount": "5.40", "currency": "USD" }
Manu Sporny: The string "USD" expands to
https://w3id.org/currencies/USD when you process the JSON-LD.
Manu Sporny: This allows you to do stuff like list prices like
this: { "amount": "1.2", "currency":
"http://example.org/currencies/chickens" } - in virtual chickens
:P
Kumar McMillan: How does the conversion happen? The reason I'm
really interested in this, when we say pricePoint: 1, it's really
cryptic. They have to look up in the documentation, look at
current exchange rates.
Kumar McMillan: If we can make it a URL, that solves a major
problem... is the amount in colombian pesos, two weeks later,
that value is no longer valid, how does that asset still be sold
if old amount is. How do you delist something for sale at a
particular price point?
Dave Longley: In PaySwarm, you can reneg on the asset by
revoking your key.
Dave Longley: Did you mean, change the price because of a
massive fluctuation in their currency?
Kumar McMillan: We're in a unique position w/ carrier billing -
fixed operator price points, we don't know how price points for
apps will change in the future. $0.99, $0.89 in Euro, the values
for that price point might fluctuate a bit.
Kumar McMillan: It would still be $0.99 in USD, but might
fluctuate in pesos.
David Bialer: We're doing this manually now... because you have
taxation, you have compliance, so price points might move...
operators don't always support the same prices... subject to
different amount of taxes... based on their own desire to add
things to it, regional tax rates.
David Bialer: You need to present the right price to the
customer, by law. We hit a lot of pain points that we didn't
expect, but now understand some of those constraints. System has
to understand it's not a simple world out there.
Kumar McMillan: Seeing an amount and a currency might not be
enough to address that specific price point problem. Sucks for
users, they might try to buy something, but it might be higher
when they go to checkout.
Dave Longley: Same thing with taxes, based on where the buyer
is, the locality might have rules to add taxes where they're
buying.
Manu Sporny: Great call today, we'll try to meet next week if
I'm back in time from the Inside Bitcoins conference, and if not,
we'll meet the week after.
-- 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 Wednesday, 24 July 2013 18:20:27 UTC