W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2014

Web Payments Telecon Minutes for 2014-08-13

From: <msporny@digitalbazaar.com>
Date: Wed, 13 Aug 2014 12:28:59 -0400
Message-Id: <1407947339404.0.19822@zoe>
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:


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

  1. Short payment identifiers
  2. Identity recovery
  3. Purchase requests
  4. Payment links
  Manu Sporny
  Dave Longley
  Dave Longley, Manu Sporny, Pindar Wong, David I. Lehn

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 
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 
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 
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 
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 
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 
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 
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 

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 
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 
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:33 UTC