- From: <msporny@digitalbazaar.com>
- Date: Wed, 13 Aug 2014 12:28:59 -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-08-13/ 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-08-13 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014Aug/0055.html Topics: 1. Short payment identifiers 2. Identity recovery 3. Purchase requests 4. Payment links Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, Pindar Wong, David I. Lehn Audio: https://web-payments.org/minutes/2014-08-13/audio.ogg Dave Longley is scribing. Manu Sporny: We're trying to get use cases in shape, we'll be handling them off to IG Manu Sporny: We can pass off identity use cases to credentials CG once started up Manu Sporny: Last time we discussed doing truly anonymous txns is probably not a 1.0 task because the technology isn't there yet Topic: Short payment identifiers Manu Sporny: Next use case: Gunther (payer) pays The Widget Store (merchant) using a short identifier. Prior to sending the payment, some information associated with the short identifier indicates to Gunther that the short identifier is a verified short identifier for the merchant. Manu Sporny: Steven Rowat said - Don't understand this one; ambiguity for me in at least two places. At first I believed the 'short identifier' was a label for the 'person', ie, identified the person to the merchant. Then I couldn't figure out the antecedent of 'them' in the second sentence (is it the person, or the merchant, or both of them?) Then in the last part of that sentence it seemed likely, but not certain, that 'short identifier for the merchant' indicates t Manu Sporny: Hat it's the merchant, not the person, who is represented by the short label. It could also mean it's representing the 'person', but provided 'for' the merchant. If I had to bet I guess I'd go with the former, rather than the latter. But I'm really not sure. Manu Sporny: For example, you can say "send $5 to ~Amazon" etc. and send a payment by looking up the identifier via a decentralized network, could alsoj ust use a domain name Dave Longley: I think he was just confused about the language around 'short identifier' [scribe assist by Manu Sporny] Dave Longley: Proposal - "Gunther makes a payment using a short identifier that identifies The Widget Store (merchant)..." Pindar Wong: Will this be internationalized/localized? Manu Sporny: Are you saying "amazon" should mean different things in different parts of the world? Pindar Wong: I'm talking about a globally-unique identifier, taking a global view from the start, this is a different layer from here, so let's just keep it simple and say globally unique is fine for now Manu Sporny: We haven't had anyone request that an identifier mean something different in different network segments and we can address it at that point if it comes up Manu Sporny: We're talking about a DNS-like system here where you can claim names Dave Longley: If we are talking about localizing things, you can build stuff on top of it. Standard should cover global namespace, but people can write localized services if they want to to do whatever mappings that they want. [scribe assist by Manu Sporny] Dave Longley: Otherwise, at some point the identifier becomes something else, standard should probably not have to concern itself on concatenation, provide some kind of aliasing service. [scribe assist by Manu Sporny] Pindar Wong: I think dave's comment caters to the localization concern Dave Longley: Proposal - Gunther (payer) enters a short-identifier that he believes identifies The Widget Store (merchant) into a UI. The UI displays a certificate of authenticity that indicates the short identifier is in fact for The Widget Store. Gunther uses the short identifier to make a payment to the store. Dave Longley: This may need to say something about the UI needing to be trusted. [scribe assist by Manu Sporny] Manu Sporny: Yeah, we're trying to stay away from trusted UI language - it's a quagmire. Dave Longley: This isn't as bad as a trusted UI problem, you just need to trust that you're paying the right person, but the payment stuff is either preconfigured so it won't go through, or you will be redirected to your payment processors site and that should take care of that particular phishing problem. [scribe assist by Manu Sporny] Dave Longley: The problem surfaces when you try to go to a non-trusted website and use the short identifier (and the website lies to you). You can sort of piggy-back on top of the SSL trust system. If you use this on the Twitter website for example, you can trust that Twitter isn't going to try and lie to you. [scribe assist by Manu Sporny] Topic: Identity recovery Manu Sporny: Next up is Design Criteria: A primary entity (buyer, merchant, etc.) with access to a credential service sets a second entity (buyer, merchant, etc.) as a backup for accessing their credentials, should they lose the ability to access the credential service (loss of password or 2-factor authentication device). Manu Sporny: This is about having a "recovery buddy" so a person or people can do something to the network to release your information and you can get your data bakc Manu Sporny: Steven's feedback on that - In theory it seems like a good idea, but maybe is too general? What are the implications...such as, will all their credentials merely switch over seamlessly at all the providers? Will all KYC and other legal entities be in the loop, or does this cause anonymity/laundering problems? By 'lose the ability', could you also be including a government taking away someone's identity or controlling it -- let's say someone in China is bl Manu Sporny: Acklisted by their government, but someone in, Oh, just for a random example, the United States government, disagrees and says, fine, we'll honor your second identity and not your first, and then everybody will be happy Dave Longley: Maybe this is too general, I think we can address that here. We didn't intend to discuss the other things he brought up. [scribe assist by Manu Sporny] Dave Longley: This was supposed to be about - if you have forgotten your password, or dropped your 2-factor device, then someone can access that account. [scribe assist by Manu Sporny] Dave Longley: If a government were to shut down your account, it would be shut down in a different way. [scribe assist by Manu Sporny] Dave Longley: I don't know how explicit we need to get here. [scribe assist by Manu Sporny] Manu Sporny: This is a design criteria that is supposed to be fairly broad, we didn't intend for those questions to be raised, but they are good questions, for example, can a gov't take away your identity Manu Sporny: There are good mechanisms in place where the gov't can revoke your gov't credentials, but not other ones that didn't issue Manu Sporny: If you have a chip in your body that requires a 2-factor device to access, and you lose that 2-factor device, I think that's what we're talking about. You lock yourself out of your own identity. Dave Longley: This is design criteria is about the person themselves denying access to themselves by accident, and then recovering from that. [scribe assist by Manu Sporny] Pindar Wong: I think that's the underlying scope of this design criteria Dave Longley: Proposal - a primary entity (buyer, merchant, etc.) with access to a credential service sets a second entity (buyer, merchant, etc.) as a backup for accessing their credentials, should they inadvertently lose their ability to access the credential service (accidental loss of password or 2-factor authentication device). Manu Sporny: Yeah, better - but now I'm wondering if we need this. You want to effectively assign power of attorney Pindar Wong: So for example on death Manu Sporny: Yes, and now I'm wondering if that should be standardized. There is huge potential here for phishing if it's standardized, maybe it should just be a feature. Dave Longley: This is another layer of abstraction on how you get into your identity - you have a password, SMS, to login.... backup email, backup password, etc. I don't think we're adding anything here by having this design criteria, It has all these knock-on effects on who owns your identity. [scribe assist by Manu Sporny] Pindar Wong: Potential to be unnecessarily complex. [scribe assist by Manu Sporny] Manu Sporny: I'm making a note that we're concerned this shouldn't be built-in into the standard, it can be unnecessarily complex while not adding anything novel Manu Sporny: Ok, on to initiating payment and wallet use cases Topic: Purchase requests Manu Sporny: First up Use Case: A buyer selects an item to purchase on merchant's site, merchant generates a purchase request that will be processed by the buyer's payment processor. Manu Sporny: Jorge is saying +1 only if generating the purchase request is equivalent to generating a link or token. Dave Longley: A token or link is just a link back to another location, a token doesn't contain enough information. At some point, you have to get the information [scribe assist by Manu Sporny] Dave Longley: Saying it can only be a link or token may be unnecessarily complex because you can't lock in a price using a URL unless the information exists in the URL, or the token is created for every time a person clicks on a link, this just seems like a bad idea - using link/token. [scribe assist by Manu Sporny] Dave Longley: Using a link/token is a premature decision. The only thing we need to say is that the purchase request either needs to have all the information in it, or it is a link to all that information. [scribe assist by Manu Sporny] Manu Sporny: I don't think we need to say if it's a link or token, etc., i think there are technically good reasons for not having it just be a token -- you can't just generate things on the fly you need a token that maps somewhere; you are adding a layer of indirection that may be unnecessary Manu Sporny: Some of these transactions are so fantastically complex that you dont' want to put all that data in a link -- and if the link doesn't have the informatino you're just using a layer of indirection that may only complicate the situation as the indirection could be unnecessary Dave Longley: If you're using links/tokens - that means that you need another layer of authentication. Added layers of complexity that may not need to be there at all. [scribe assist by Manu Sporny] Topic: Payment links Manu Sporny: Next up Use Case: A developer can create a link with a specific payment URI scheme or rel-type such that when a buyer clicks on it, the buyer's payment processor starts the payment process. Manu Sporny: Adrian said - updated use case - Is URI scheme the only way to do this? Manu Sporny: Jorge says - this is my favorite approach. No NASCAR problem, no list of payment processors, just an email with a payment link. It could be implemented with a simple form with text field for inputs like 'wallet.example.com/walletID' or 'walletID@walletexample.com' (maybe with a drop down menu), make an API call to the example provider and let the provider send the email with the payment link if the transaction is possible. Manu Sporny: Discussion around Jorge's input - not preferred mechanism, doesn't go far enough, people shouldn't have to remember their wallet ID or their information. If we are going to do what Jorge proposes, there is no innovation there. It's just asking people to type in their address to their payment provider. Dave Longley: This approach wouldn't build Web Payments into the web, it would be on top of it, using a typical form. [scribe assist by Manu Sporny] Pindar Wong: It's going in entirely the wrong direction (not trying to be out of line), but not where we want to go, also may introduce unexpected behavior Pindar Wong: Jorge's proposal is going in entirely the wrong direction. It also might generate an element of surprise, we're trying to make it easier to use this technology by pushing the complexity down, not surfacing it in the form of a form input for a wallet ID. [scribe assist by Manu Sporny] Manu Sporny: Next up Use Case: When a payee intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the payee. Manu Sporny: Jorge's input is that this is the NASCAR problem. Dave Longley: This is a misunderstanding of the NASCAR problem - who is deciding what the set of options are - you or the merchant. if you are able of picking from payment processors that only you have, that's fine. [scribe assist by Manu Sporny] Dave Longley: There is an element here about an intersection of payment processors, merchant only supports a small number, you only have a small number, so you're only going to see payment processors that you're interested in. [scribe assist by Manu Sporny] Dave Longley: As michael williams commented, we'd fully expect browsers or payment processors to choose defaults. [scribe assist by Manu Sporny] Manu Sporny: Yeah, ideally you'd be able to set a default, joseph potvin has talked about setting a default price index too, etc. we want to make setting defaults the way things are done to make it as easy as possible Pindar Wong: Agreed David I. Lehn: Yeah, don't think they're familiar w/ the technology that's being proposed, it's specifically designed to avoid the NASCAR issues. Pindar Wong: There seems to be a mentality that is related to the current situation that will be very different once this solution is deployed Manu Sporny: Next week we have to cancel because i'll be doing a keynote at semtech
Received on Wednesday, 13 August 2014 16:29:27 UTC