Web Payments Community Group Telecon

Minutes for 2011-10-21

  1. Newest Editor's Draft of PaySwarm Use Cases
  2. Simple Payment Request
  3. Point-of-Sale Support
  4. Requirements Discussion
  5. Digital Signatures
  6. Currency Exchanges
Manu Sporny
Mike Johnson
Manu Sporny, Pelle Braendgaard, David I. Lehn, Mike Johnson, Jeff Sayre
Audio Log
Manu Sporny is scribing.
Pelle Braendgaard: I was at IIW - we created a new draft for OpenTransact - some of that stuff is relevant. [scribe assist by Manu Sporny]
Pelle Braendgaard: IIW was good - OpenID and OpenID Connect are getting finalized - they look good. [scribe assist by Manu Sporny]
Manu Sporny: Do they allow associating public keys with the ID? [scribe assist by Manu Sporny]
Pelle Braendgaard: They use JWT - it includes a signature and encryption component. [scribe assist by Manu Sporny]
David I. Lehn: Google in-app payments is also using JWT
Mike Johnson is scribing.

Topic: Newest Editor's Draft of PaySwarm Use Cases

Manu Sporny: First topic is new editors draft
Manu Sporny: breaks the use cases out into PaySwarm 1.0 cases, future cases. Organized from simple to complex/optional cases.
Manu Sporny: Do not include cases which haven't been discussed in these meetings yet.
Manu Sporny: We still need to discuss Pelle's two extra use cases.

Topic: Simple Payment Request

Manu Sporny: One is simple payment request, other is point of sale payment device.
Manu Sporny: First up is simple payment request.
Pelle Braendgaard: That covers my use case.

Topic: Point-of-Sale Support

Pelle Braendgaard: Here are 2 examples of this using OpenTransact
Pelle Braendgaard: http://pays.ms
Pelle Braendgaard: http://capcard.heroku.com/
Manu Sporny: Example - any time this visa card is swiped it doesn't have to go over Visa, it could go over PaySwarm and the merchant could pull funds and avoid credit card charges.
Manu Sporny: Merchants may not be able to do that, Visa terms of service may not allow it.
Jeff Sayre: How is this different than PayPal? PayPal is be tied to credit card accounts.
Manu Sporny: We don't have a definitive answer for that. It probably still runs transaction over Visa network, but this idea would be to avoid running over Visa.
Manu Sporny: Example - Square's credit card swipers that plug into your phone - they probably still process via Visa network, but we don't /have/ to go over any particular network.
Manu Sporny: Needs to be a service to figure out how to map CC numbers to the person who has the account. But this would be more than what Pelle's use case would cover.
Pelle Braendgaard: The payment provider would have different sponsored or third party card providers.
Pelle Braendgaard: Replacement of the existing ISO payment card system.
Pelle Braendgaard: At Future of Money, at least 4 different mobile payment providers all with different front ends: SMS, etc. But all had to tie into one backend.
Pelle Braendgaard: With this front end payment providers could just link in without having to worry about backend.
David I. Lehn: Does this use case address purchases from vending machines?
Pelle Braendgaard: If there is a simple approach to doing this, then it could be used for all types of applications. [scribe assist by Manu Sporny]
Manu Sporny: This is important and we should consider it for PaySwarm 1.0.
Manu Sporny: I'm concerned that the use case is too general, and needs to be broken up into more specific cases.
Manu Sporny: Visa replacement, vending machines, SMS messages, etc.
Pelle Braendgaard: The vending case may be different since it is more for merchants than the consumer side.
Manu Sporny: Ok, so we'll split into consumer/merchant cases for this use case.
David I. Lehn: I think there are many possible ways to implement these sorts of systems so maybe the use case could just cover the general idea?
Pelle Braendgaard: It's just a physical dongle - you can build anything on top of that.
Manu Sporny: This needs to be more specific, for instance think about disconnected operations.
Manu Sporny: A vending machine doesn't have an internet connection.
Manu Sporny: Vending machine could negotiate contract, keep contracts, upload for processing later.
Manu Sporny: Encrypted signed contract would route the contract through the buyer, allows the vendor to not have to contact the PaySwarm Authority.
Pelle Braendgaard: That introduces a great deal of complexity.
David I. Lehn: Personally, I like thinking about how to solve these sorts of issues :)
Pelle Braendgaard: Maybe we should have someone else create another layer on top, rather than supporting it in the underlying layer.
Mike Johnson: This use case already parallels what we've done - don't know if people are aware of how PaySwarm works - current purchases are always securely routed through the buyer... so this is already supported. [scribe assist by Manu Sporny]
David I. Lehn: I see PaySwarm providing the low level plumbing that will let you try out various implementations at a higher level.
David I. Lehn: We just want to make sure the use cases are sufficient to make sure the plumbing is good enough.
Mike Johnson: I think the example of having a cellphone and using NFC via vending machine and the cellphone supporting it is already supported... [scribe assist by Manu Sporny]
Jeff Sayre: +1 on Mike's description
Manu Sporny: We want to have that part already thought out. Supports putting this use case in there because we've already solved that problem.
Pelle Braendgaard: It might make other cases more complicated, but we can leave that use case in.
Pelle Braendgaard: Let's try to minimize it making other use cases more complicated.
Manu Sporny: First - buyer's side of the process. Buyer uses physical device to make a purchase using these standards.
Manu Sporny: Second - merchant's side of the process. Merchant has device and uses what customer provides or keys something in that allows them to use the standard.
Manu Sporny: Third - Proxy purchases. A vending machine routes payment requests through a phone or buyer's device, customer passes on to PSA and routes back to device to prove that customer has securely purchased.
Manu Sporny: That should cover point of sale devices.
Pelle Braendgaard: No other uses cases at the moment.
Manu Sporny: We can add more later as we come across them.
Manu Sporny: use cases are important, RDFa suffered from not having an updated set of use cases.

Topic: Requirements Discussion

Manu Sporny: This is to see if the set of requirements we were discussing all have use cases to support them.
Manu Sporny: First up is proof of purchase. (Digital contracts) We have the use case documented - 2.11 Proof of Purchase
Manu Sporny: Next is Digital Signatures. Pelle had concerns about digital sigs, but we may need to discuss on the mailing list.

Topic: Digital Signatures

Pelle Braendgaard: Offline devices are a good technical reason to use dsigs, but there does not seem to be a legal reason to use it.
Manu Sporny: Digital signatures are more for security than legal upholding.
Manu Sporny: Dsigs allow things like offline use and allow us to list assets for sale and allows secondary market.
Manu Sporny: Comes into play for multiple download sources for content, and the buyer needs to prove that someone bought something.
Pelle Braendgaard: Don't think it's necessary. Dsigs don't hurt, but it does make it more complex. Would support it as optional.
Pelle Braendgaard: OpenID Connect has a concept of claim. Things can be signed but it is not required.
Jeff Sayre: +q
Pelle Braendgaard: I don't think it buys us anything except looking cool technically.
Jeff Sayre: Should be suggested, requirement may be optional.
Pelle Braendgaard: +q
Jeff Sayre: Would prefer they are included but we should investigate.
Manu Sporny: Qe need to be clear about what we mean by digital signature. We need to not lump it in the same basket as all other security/crypto.
Manu Sporny: When we say digital signatures we actually lump in other crypto in there too.
Manu Sporny: SSL is hidden from developers, but signatures are more visible.
Manu Sporny: SSL also requires certificates. Cost for operating your vendor now means you have to have a certificate - that's $30-$50 per year to setup one store.
Manu Sporny: We shouldn't assume everyone wants or can buy an SSL certificate for each vendor they have.
Manu Sporny: Buying an SSL cert doesn't lower the barrier to entry enough. We want people in developing nations to be able to use this technology, and for them - spending $30/year is not an option.
Manu Sporny: Pelle's arugment that it is more complex is true. But we would provide libraries to wrap almost all of that up so that it is as invisible as SSL.
Manu Sporny: Libraries would be open source, etc.
Manu Sporny: All of that to say, we want to drive costs of operating in PaySwarm network as close to zero as possible. Requiring SSL certificates is not a good start for the people we want to draw to use this.
Pelle Braendgaard: The cost issue, most small vendors would use a service provider to do it. They wouldn't develop it from scratch.
Pelle Braendgaard: Lessons from OAuth 1.0, even though there are good libraries, people would develop one themselves and fail, didn't understand and would implement an incorrect library.
Pelle Braendgaard: Requiring OAuth 2.0 to use SSL has dropped a lot of that.
Manu Sporny: Anything over HTTP is not secure.
Jeff Sayre: Also an issue with PCI compliance in the US?
Manu Sporny: Problem with PCI compliance is it is made for an idustry that doesn't keep in mind security too much. So, there may be an issue - but this is a completely different payment mechanism we're talking about - with security built in from day one.
Manu Sporny: If people write an implementation of this incorrectly, it just doesn't work - the digital signatures, hashes, etc. ensure that one has to be very specific and clear about the transaction that is occurring.
Pelle Braendgaard: IETF's Security Analysis of OAuth 2 http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00
Manu Sporny: There is a way to implement a spec to allow us to not shoot us in the foot, must be aware of all attack vectors.
Manu Sporny: There are trade-offs between SSL only versus SSL in some parts and allowing other parts to be done over non-SSL. You can't look at the problem and just say that everything must be run over SSL.
Manu Sporny: PaySwarm authorities have to have SSL, but vendors would not need to buy one. People who would need an SSL cert would be the people who would have to buy one.
Jeff Sayre: Self signed certificates?
Manu Sporny: No, because the PSA doesn't know if it can trust you saying you are the person with a self-signed certificate.
Manu Sporny: If browser doesn't do network perspective reasoning on certificates, like what is done at http://convergence.io/, it fails. We wouldn't be talking about this if browsers did that already. The whole Certificate Authority system is broken currently - Network Perspectives are the best way out of it right now.
Pelle Braendgaard: Payment Authority requires it, but vendor does not.
Pelle Braendgaard: Similar to how Facebook connect works.
Pelle Braendgaard: Facebook connect is a widget you paste into an HTML page.
Manu Sporny: If it is simpler and addresses all security concerns then should adopt the technology. I am not convinced that Facebook connect solves our problem. There is a big difference between performing a purchase and someone signing into your facebook account.
Pelle Braendgaard: They have spent two years looking at threat model of OAuth 2.0
Manu Sporny: We should use that to investigate our own threat models.
Jeff Sayre: We need to better understand the whole system to understand our security issues.
Jeff Sayre: It's crucial to find out where the threats really are.
Manu Sporny: We will keep the dsig discussion going.

Topic: Currency Exchanges

Manu Sporny: Multiple currency use case is 2.8, so that's covered
Manu Sporny: Simple transfer from one account to another - I think Payment Links handle that, right?
Pelle Braendgaard: Payment link is just request for payment, but the actual payment process is different. Currency exchanges - that's basically covered.
Pelle Braendgaard: The most basic action, is part of all of them.
Pelle Braendgaard: Covered by all other use cases.
Jeff Sayre: Exception might be a pure currency conversion, Euros to Bitcoin.
Pelle Braendgaard: An exchange would require two transfers, so it's covered.
Pelle Braendgaard: Person A transfers asset to Person B. Person B transfers asset to Person A.
Jeff Sayre: Future of Money scenario, it's more of an open exchange where PSA is intermediary.
Jeff Sayre: Transactions would match two external parties and does an open exchange instead of a currency converter where the PSA has balances of all currencies.
Pelle Braendgaard: Technically the would probably be the same, it's how the exchange covers it in their backend. Use cases covered in OpenTransact for exchanges.
Jeff Sayre: A use case for an open exchange is not necessary? I think it is necessary.
Pelle Braendgaard: They would be the same, more like a business decision than a technical requirement.
Pelle Braendgaard: Market matcher vs Market maker.
Jeff Sayre: Do we need a specific use case for currency exchange?
Jeff Sayre: 2.8 is just alternate currencies.
Manu Sporny: Probably a good idea to have a use case for a currency exchange. I mean, we're talking about it and we're saying it should be supported.
Jeff Sayre: Future of Money will be interested in that.
Pelle Braendgaard: We don't need to split all of these cases, for instance asset means something very general. Use cases for an asset includes mp3, physical goods, etc.
Manu Sporny: Jeff we should be explicit about use cases. Pelle had to explain why they are the same. We agree on a technical reason, but use cases are to spell out these things.
Manu Sporny: We will put in a use case on currency exchange into the spec.
Manu Sporny: There are 4 requirements left, let's leave those until next time.
Manu Sporny: Let's meet again in two weeks to discuss requirements more.

Created by the Web Payments Community Group. Shared with love under a CC-BY license.