Web Payments Community Group Telecon

Minutes for 2014-07-01

Dave Longley is scribing.
Manu Sporny: Any updates or changes?
David I. Lehn: Nope

Topic: Decentralized identity information

Manu Sporny: This is the use case we have right now - Use Case: Place and update identity information in a decentralized network (replace payment providers, e-mail attestation, etc.)
Manu Sporny: Is this more like a design criteria?
Manu Sporny: "Do not allow a person's payment or identity information to be locked down to any particular provider"
Dave Longley: I agree - sounds like design criteria where that is the goal. Need payment / identity information to be portable. [scribe assist by Manu Sporny]
Manu Sporny: So, we're doing this as a design criteria, then?
Dave Longley: Somewhere we said that you could switch payment providers easily? [scribe assist by Manu Sporny]
Manu Sporny: We do have this - The customer decides to switch to a different identity/wallet/data storage provider and all of their wallet and credential data comes with them.
Dave Longley: Yeah, so we have that, so this is just a general design criteria to prevent vendor lock-in. [scribe assist by Manu Sporny]
Manu Sporny: So, something like this - Design Criteria: Ensure data portability via the use of, for example a decentralized network for data storage, and also prevent single point of failure by use of the same.
Dave Longley: Maybe we should say - ensure that it's a requirement. [scribe assist by Manu Sporny]
Manu Sporny: We'll need to mention a core set, because people will want to value add
Manu Sporny: So - Design Criteria: Require data portability for customer financial and identity data?
Manu Sporny: "Do i have to export all of my data or just some of it"
Manu Sporny: Design Criteria: Require data portability for customer financial data and identity data that is required for core transaction functionality.
Manu Sporny: So, that?
Dave Longley: It would be annoying for transaction/receipt data to not be portable - we should require any metadata associated with receipts to also be portable, or maybe we say "choose a payment processor that will port all of your related data"? [scribe assist by Manu Sporny]
Dave Longley: I think that design criteria is fine, let's strike the use case and move on. [scribe assist by Manu Sporny]

Topic: Premium SMS

Manu Sporny: So we have this Use Case now: Determine how Premium SMS (operator billing) works with a Web payments solution.
Dave Longley: We should change this into a design criteria as well - "Ensure Premium SMS is compatible/works with the Web payments olution" [scribe assist by Manu Sporny]
Manu Sporny: We don't call out Visa/Mastercard, so why Premium SMS? Maybe we should call all of the ones we can think of out. [scribe assist by Manu Sporny]
Manu Sporny: The point is, we want to make sure that the system is flexible enough to support most of the current legacy payment systems in use today.
Dave Longley: "Design Criteria: Ensure the Web payments solution can use legacy payment methods (eg: credit card, Premium SMS, ...)"
Dave Longley: There needs to be some sort of translation layer there. Web Payments can provide a transaction layer that can integrate w/ legacy payment methods... that's what we want to say. [scribe assist by Manu Sporny]
Dave Longley: "Design Criteria: Ensure the Web payments solution can provide an abstraction layer that integrates with legacy payment methods (eg: credit card, Premium SMS, ...)"
Manu Sporny: Close, we want to list a few more things by name to make sure people understand the scope.
Manu Sporny: Design Criteria: Ensure the Web payments solution can provide an abstraction layer that integrates with existing payment methods (eg: VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.)

Topic: Financial Regulatory Hooks

Manu Sporny: Here's what we have now - Use Case: Enable financial regulation (e.g. reporting above a certain value) to be implemented directly in payment protocols
Manu Sporny: This was brought up by multiple people, bloomberg, us fed, to come up with hooks that link into the system, so that transactions that go over a certain amount/go to a certain person and being able to wrap that info up and send it to the proper authority and have the authority be able to capture that information, so there's an open system for reporting over $10k txns, rather than some closed system to do it
Manu Sporny: I think it's going to be highly unlikely that we could specify the protocol for what the server would accept for a regulatory hook, so instead of a transaction so we could have a hook or class or something to put a transaction in there to report to the proper authorities
Dave Longley: Couldn't this just be more vocab terms in the receipt itself? Something you send to the proper authority? The payment processor sends it. [scribe assist by Manu Sporny]
Manu Sporny: Why would the payment processor put regulatory fields in the receipt?
Dave Longley: Transparency. Important to make possible, but maybe we shouldn't mandate it in the spec. [scribe assist by Manu Sporny]
Dave Longley: What's important is that you can include that information, and it can be in the receipt if we want it to be. [scribe assist by Manu Sporny]
Manu Sporny: It does boil down to that, but the regulators also wanted to be told what the protocol would be so they could set up systems to get digitally signed statements of "this is a 10k transaction"
Dave Longley: We have machine-readable data in the current design in the receipt, so we have all of that in the current design. [scribe assist by Manu Sporny]
Manu Sporny: The regulatory event might not be part of a single transaction, it might be triggered after 500 different transactions on a particular day, or it has to do with the purchase of a good/service in a certain country or you need licensing and you're just reporting that someone purchased that item so the gov't can follow up, pretty scary use case, but it's not just ... we have the core infrastructure to do this in the digital receipt mechanism we have but i think what we need is some way of telling the regulators "here's your hook, now you have to tell us the format of the thing that you need", for example, in the US, "this is the FINCEN URL that you post all the regulatory messages to" and then that's something that is managed by FINCEN
Manu Sporny: I think what we want is something that allows a payment processor to send a stream of regulatory events to a regulator-provided URL.
Dave Longley: So, we are talking about two services? A machine-readable document that says what messages need to be posted, and another the is a drop box for regulatory messages? [scribe assist by Manu Sporny]
Manu Sporny: I think we only need the second part, the first part will be human readable (it's complex)
Dave Longley: "A payment processor tracks financial regulatory events and submits machine-readable information to a government URL to meet regulatory compliance."
Dave Longley: The government has certain regulatory requirements wrt. transactions. In order to make the government and the payment processor operate more efficiently, a URL is provided that helps the payment processor stay in compliance and the government to collect important regulated financial events. [scribe assist by Manu Sporny]
Manu Sporny: How about - Use Case: A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.
Dave Longley: Presumably, they'll also have to track receipts and other information in case of an audit. [scribe assist by Manu Sporny]

Topic: Transaction Rights/Responsibilities

Manu Sporny: We currently have this - Use Case: Rights & responsibilities of a transaction being associated with the context of the transaction, and conveyed to parties in the transaction.
Dave Longley: This has to do w/ including licensing/terms of use information for whatever good/service has been purchased. I think we can reword this as a use case - PaySwarm already supports it. [scribe assist by Manu Sporny]
Dave Longley: "A customer purchases access to a service on a vendor's website. Included in their digital receipt is a machine-readable license that indicates what kind of access they've been granted and for how long."
Manu Sporny: Maybe we need to say "rights and responsibilities"
Dave Longley: "... The vendor can use this license to enforce access to the service." (useful to add?)
Manu Sporny: So, how about - Use Case: A customer purchases access to a service on a vendor's website. Included in their digital receipt is a machine-readable license (rights and responsibilities) that indicates what kind of access they've been granted and for how long. The vendor can use this machine-readable license to enforce access to the service.

Topic: Digital Receipts

Manu Sporny: We have this - Use Case: Issue, transmit, validate proof-of-purchase / digital receipt.
Dave Longley: We should mention that this digital receipt is cryptographically secured. [scribe assist by Manu Sporny]
Manu Sporny: What about - Use Case: A customer purchases a good or service from a vendor resulting in a cryptographically secured, machine-readable, digital receipt that is issued to the customer. The vendor may then use the receipt as a proof-of-purchase for the good or service.
Dave Longley: Use "signed" instead of "secured". [scribe assist by Manu Sporny]
Dave Longley: "A vendor cryptographically-signs an offer for a good or service. A customer purchases the good or service..."
Manu Sporny: Ok, so this is the result of those edits: A vendor cryptographically-signs an offer for a good or service. A customer purchases the good or service from the vendor resulting in a cryptographically signed, machine-readable, digital receipt that is issued to the customer. The vendor may then use the receipt as a proof-of-purchase for the good or service.
Dave Longley: We may want to modify this one further and strike the next one [scribe assist by Manu Sporny]
Dave Longley: We should strike this one - Use Case: Create a common digital receipt format. [scribe assist by Manu Sporny]
Dave Longley: Since we already cover that - we may also want to strike the next one as well. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so strike this use case too? - Use Case: Prove ownership over a particular asset (proof of purchase / ownership).
Dave Longley: Yes. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so we're left with this, then: A vendor cryptographically-signs a standardized offer for a good or service. A customer purchases the good or service from the vendor resulting in a standardized, cryptographically signed, machine-readable, digital receipt that is issued to the customer. The customer or vendor may then use the receipt as a proof-of-purchase for the good or service.
Manu Sporny: This use case now feels like it should be split apart. [scribe assist by Manu Sporny]
Dave Longley: Well, this whole thing is a process. Let's just leave it in as a full use case. When the Web Payments IG comes through on the 2nd pass, they can split it up if they want to. [scribe assist by Manu Sporny]

Topic: Digital Receipt Storage

Manu Sporny: We currently have this - Use Case: Customer can receive digital receipts (receipt POSTed to user's digital receipt storage vs. an emailed receipt).
Dave Longley: Don't quite understand the use case? [scribe assist by Manu Sporny]
Manu Sporny: Some people were saying you were just emailing, but it would be nice if every time you made a purchase it could be posted to a URL for your own personal storage
Dave Longley: Let's just update this use case - it's pretty close - A customer stores their wallet, credentials, *and digital receipts* with a particular identity/wallet/data storage provider. The customer decides to switch to a different identity/wallet/data storage provider and all of their wallet, *receipt*, and credential data comes with them. [scribe assist by Manu Sporny]
Manu Sporny: Ok, then we delete the last use case?
Dave Longley: Yeah. [scribe assist by Manu Sporny]

Topic: Uncategorized/Out of Scope Use Cases

Manu Sporny: We still need to go through the majority of the uncategorized and out of scope use cases. There are a number of them, but a quick read through the first half of them shows that we've already either covered many of these use cases or we've

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