- From: <msporny@digitalbazaar.com>
- Date: Wed, 18 Jun 2014 15:49:04 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes for this week's Web Payments telecon are now available: https://web-payments.org/minutes/2014-06-17/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Web Payments Community Group Telecon Minutes for 2014-06-17 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0126.html Topics: 1. IGF Workshop on Identity 2. Whitelisting 3. Automated Payments and Subscriptions 4. Theft of Payment Details 5. Intent to Pay 6. Wallet Data Synchronization 7. Decentralized Identity Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Pindar Wong Audio: https://web-payments.org/minutes/2014-06-17/audio.ogg Dave Longley is scribing. Manu Sporny: Anything to add to the agenda? David I. Lehn: Nope Manu Sporny: Actually, one thing to add to the agenda - we need to review IGF stuff Topic: IGF Workshop on Identity Manu Sporny: Here's the workshop description: http://www.intgovforum.org/cms/wks2014/index.php/proposal/view_public/69 Manu Sporny: The deadline to update that is on the 20th, which is this friday Pindar Wong: I will email IGF a/c details by email to Manu Manu Sporny: I've sent emails out to bloomberg, mozilla, US fed, some others Manu Sporny: I've asked them to confirm by the 20th if they haven't already Manu Sporny: The other issue is that there was a problem trying to submit what we were trying to submit to the IGF, and pindar submitted that on my behalf, so only he can edit the proposal, but i can't edit the proposal so i'll have to send the edits through pindar and make sure he applies those Manu Sporny: I think we answered all the questions the IGF asked of us, in fact we had answered them before, meaning that the things that they asked us to clarify we had already clarified Manu Sporny: So they wanted the complete list of panelists with their status as confirmed, we're trying to confirm them, the agenda of the workshop which we have, and they want a remote mod for the workshop which we also put in the proposal Manu Sporny: They want to increase gov't participation in the panel and we've asked the US fed to join Manu Sporny: We asked w3c, world bank, bloomberg, and mozilla to respond Manu Sporny: We think w3c and think world bank will be there Pindar Wong: That’s great if the US Fed can join Manu Sporny: We can try and bring the ripple folks in as well and i think i sent something out to ask them to participate Manu Sporny: They asked us to frame the policy questions more clearly. I'll update the current proposal. Topic: Whitelisting Manu Sporny: Ok, we had a combined use case that we were dealing with last week - Whitelisting like MozPay API where customer needs to figure out which payment providers are supported by the merchant. Customer and merchant need to be able to select a payment processor that are compatible. Manu Sporny: I think we dealt with the first item: Whitelisting like MozPay API where customer needs to figure out which payment providers are supported by the merchant. Manu Sporny: But we didn't deal with the second item: Customer and merchant need to be able to select a payment processor that are compatible. Dave Longley: This use case is about the merchant being able to advertise the payment mechanisms they support, and the customer being able to select which ones they have and which ones they want to use. [scribe assist by Manu Sporny] Dave Longley: So, the use case is - A customer goes to a merchant website, and upon initiating a payment, the merchant provides the payment providers that they support and the customer selects the one that they want to use for the purchase. [scribe assist by Manu Sporny] Dave Longley: Unfortunately, that just sounds like the state we're in right now - we want to make sure that people know that this process is automatic. [scribe assist by Manu Sporny] Manu Sporny: Right, we want to make sure that people know that this should be an automatic/automated process (as much as it can be). Dave Longley: The merchant's software transmits the merchant's payment processor options to the customer's software. The customer's software presents a choice of payment processors the customer has previously registered with that are compatible with the merchant's payment processors Manu Sporny: So if the merchant says: I support Credit Card, ACH, and Bitcoin, and the customer supports Credit Card and Bitcoin, then the options presented to the customer will be: "How do you want to pay? Using your Visa card, or Bitcoin?" Manu Sporny: Ok, so this is the use case, then: A customer goes to a merchant website, and upon initiating a payment, the merchant's software transmits the merchant's payment processor options to the customer's software. The customer's software presents a choice of payment processors the customer has previously registered with that are compatible with the merchant's payment processors. Topic: Automated Payments and Subscriptions Manu Sporny: This is the use case we have today: Automatic payments, transparent to usage (subscriptions and safe pay-as-you-go w/o asking/annoying the customer) Manu Sporny: So, basically what we want to enable here is a customer going to a website, selecting a payment method and then authorizing the website to pull an amount of money (with limits) from their account on a weekly, monthly, yearly, etc. basis. Dave Longley: What about: A customer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to subscribe or add a pay-as-you-go token for future purchases from the merchant. Manu Sporny: It's not just the payment processor - the merchant could ask them to subscribe. Dave Longley: I was trying to be vague on purpose - the merchant would include that information in the information they'd pass on to the payment processor. [scribe assist by Manu Sporny] Manu Sporny: Ok Dave Longley: The merchant would include information indicating that they'd like the customer to subscribe/add a pay-as-you-go token Topic: Theft of Payment Details Dave Longley: The payment processor would present that to the customer Manu Sporny: So, we have this right now - Use Case: Theft of payment details results in very low return on investment. Dave Longley: I think we have this use case covered. [scribe assist by Manu Sporny] Manu Sporny: We already have this one - Use Case: A customer executes a transaction without revealing secrets that are not vital to the transaction (i.e. identity, passwords, PINs or other information that the merchant does not need to know). Manu Sporny: And we also have this one: Use Case: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Tokenization mechanism that protects the buyer and merchant from theft of credentials. Manu Sporny: So, I think we're covered. Dave Longley: Yeah, both of those cover this use case [scribe assist by Manu Sporny] Manu Sporny: Ok, so we're striking - Use Case: Theft of payment details results in very low return on investment. Topic: Intent to Pay Manu Sporny: This is the use case that we have for this one: Decouple payments as much as possible. Base on an intent-to-pay mechanism Manu Sporny: This was a proposal made by robin berjon Manu Sporny: He said that we could use something like a protocol handler Manu Sporny: We could revive the web intents stuff or add a protocol handler for initiating a payment Manu Sporny: For any new payment mechanism you wanted to add to the web could just be a new protocol Manu Sporny: We should explore this design criteria Manu Sporny: We need to phrase it in a way that's useful Manu Sporny: I listed this as a design criteria, it's not really a use case Dave Longley: I'm trying to figure out how it's different from the use cases we've discussed thus far. This sounds like an implementation detail (the use of web intents or protocol handlers) [scribe assist by Manu Sporny] Dave Longley: That is, you initiate a transaction and hand the data blob over to the protocol handler. [scribe assist by Manu Sporny] Dave Longley: This is really a question of whether or not we have a specific payments API for browsers, or if we should use a protocol handler or a Web Intent. [scribe assist by Manu Sporny] Dave Longley: I think payments are decoupled already regardless of what the implementation detail would be. [scribe assist by Manu Sporny] Manu Sporny: I don't know if we would consider web intents or protocol handlers very heavily if we didn't have anything in there mentioning it Manu Sporny: I'm concerned that we're going to overlook Web Intents or Protocol Handlers if we don't preserve this in some way. Manu Sporny: So, something like this? Design Criteria: Consider using Web Intents or Protocol Handlers to provide a more abstract implementation solution for payment initiation as well as a technology that could be used for solving other intent-related problems on the Web. Dave Longley: What about: Consider using Web Intents or Protocol Handlers to provide an abstraction layer that could be used to solve both payment initiation and other problems on the Web. Manu Sporny: Ok, sounds good. Topic: Wallet Data Synchronization Manu Sporny: We have this use case now: Sync wallet data, password data, and credential data to the cloud - use the same mechanism for all three. Manu Sporny: This was proposed as a general cloud storage mechanism Manu Sporny: I think that wallet and credential data are supported by the identity credential spec and you could argue that password is as well Manu Sporny: It's also RWW (read write web) stuff Manu Sporny: You write things to your personal data space online Manu Sporny: Your personal data vault, is another way to put it Manu Sporny: I think the basic use case is being able to store your private information in a place of your choosing that is not the originator of that data Dave Longley: The purpose of standardization here is so that you could just click a button and switch your data to another storage location. We're talking about a storage API for data. [scribe assist by Manu Sporny] Manu Sporny: It does seem like the main thing we're talking about is ensuring that you can store your data securely in some place and that you can change that location at will. Dave Longley: I don't think that inventing a whole other API to do that is useful. [scribe assist by Manu Sporny] Dave Longley: I think the use case is more about making it easy for people to store their data where they want to store it rather than synchronizing their data. [scribe assist by Manu Sporny] Dave Longley: Effectively, this is about discoverability and reading that information (which needs to be standardized in some way). [scribe assist by Manu Sporny] Dave Longley: Where you write the data doesn't need to be standardized. That's what the sync thing is about. In the Identity Credentials spec, we do talk about other people being able to write to your personal data vault. [scribe assist by Manu Sporny] Dave Longley: If there were 3 different providers for storing your personal data, you could switch to them based on the software you're using. As long as the 3 storage mechanisms allowed reads and discoverability in the same way, you could sync to all three. [scribe assist by Manu Sporny] Dave Longley: Maybe this is too far down in the weeds. Maybe the use case should be: A customer is storing their wallet, credential data, passwords, and other sensitive information at one identity provider / wallet provider, then they should be able to switch to a new one and make a payment w/o going through a painful setup process. [scribe assist by Manu Sporny] Dave Longley: I'm wondering if we don't already have this covered. [scribe assist by Manu Sporny] Dave Longley: This is another design criteria - decouple storage of your identity information from where your identity provider is. [scribe assist by Manu Sporny] Manu Sporny: Also, keep in mind that we have this use case next - Wallet portability to move to a new wallet service provider at will. Dave Longley: Well, doing that requires that you are able to move your data with you (synching it across websites easily) [scribe assist by Manu Sporny] Dave Longley: Proposal: A customer currently stores their wallet and credentials with a particular identity/wallet provider. The customer decides to switch to a different identity/wallet provider and all of their wallet and credential data comes with them. Manu Sporny: So, that takes care of both use cases? Dave Longley: Yeah, I think so [scribe assist by Manu Sporny] Manu Sporny: I agree, I think... trying to think if there is any part of both of those use cases that aren't covered with the text above. Manu Sporny: Ok, so reword: A customer stores their wallet and credentials 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 and credential data comes with them. Dave Longley: I don't think we need to standardize /how/ the data is stored... just the protocol for querying and retrieving the data. [scribe assist by Manu Sporny] Dave Longley: All we need to standardize is the mechanism that allows you to easily move the data between providers. We have that with the Linked Data solution - you'd expect the data to be available in the cloud, but you can also run your own data provider and run it all on one device w/o any backups and lock it down to that device. [scribe assist by Manu Sporny] Dave Longley: You still have to provide access to it if anyone wants to interface w/ you. [scribe assist by Manu Sporny] Dave Longley: What I'm trying to say is that we were originally trying to conflate too many things, and if we focus too much on all this "cloud" stuff, we lose the kernel of the problem that needs to be solved. [scribe assist by Manu Sporny] Dave Longley: Other people need to be able to get access to whatever data they need to complete a transaction w/ you. Whatever minimal set of data that needs to be transferred to that. [scribe assist by Manu Sporny] Dave Longley: You also need to be able to give another storage provider access to the data to move/migrate/sync it. All that we require of the data provider is that if someone wants to change data providers, they can do so. [scribe assist by Manu Sporny] Dave Longley: I'm pretty sure the Identity Credentials spec handles this stuff now... there are implementation details we need to work out, but the general design is capable of addressing these issues. [scribe assist by Manu Sporny] Manu Sporny: Ok, so we're accepting that use case above and striking the two in there now - removing sync specifics, since portability should take care of synching as well. Topic: Decentralized Identity Manu Sporny: We only have a few items left in payment initiation... decentralized identity is one of them... two use cases. Dave Longley: They could be combined. [scribe assist by Manu Sporny] Manu Sporny: Agreed, let's do that. Dave Longley: These are really identity use cases [scribe assist by Manu Sporny] Manu Sporny: Yeah, ok out of time for today. We'll chat again next week - same time and day of week. Tuesday 9:30pm Boston.
Received on Wednesday, 18 June 2014 19:49:27 UTC