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

Web Payments Telecon Minutes for 2014-09-10

From: <msporny@digitalbazaar.com>
Date: Wed, 10 Sep 2014 16:36:12 -0400
Message-Id: <1410381372363.0.31008@zoe>
To: Web Payments CG <public-webpayments@w3.org>
Thanks to David I. Lehn and Dave Longley for scribing this week! The minutes
for this week's Web Payments telecon are now available:

https://web-payments.org/minutes/2014-09-10/

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

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Sep/0015.html
Topics:
  1. IGF 2014 - Web Payments/Credentials Workshop Review
  2. Payment Initiation / Wallet Use Case Revisions
  3. Loyalty Cards
  4. Variable Pseudo-anonymity
  5. Offers and Price Quotes
  6. Native App Purchases
Chair:
  Manu Sporny
Scribe:
  David I. Lehn and Dave Longley
Present:
  David I. Lehn, Manu Sporny, Dave Longley, Timothy Holborn, Evgeny 
  Vinogradov
Audio:
  https://web-payments.org/minutes/2014-09-10/audio.ogg

David I. Lehn is scribing.
Manu Sporny:  Any updates to agenda?

Topic: IGF 2014 - Web Payments/Credentials Workshop Review

Manu Sporny:  We went over the IGF workshop on yesterday's 
  Credentials CG call, so let's just refer to that discussion.
Manu Sporny: Here's the transcript from the Web 
  Payments/Credentials workshop at IGF 2014: 
  http://www.intgovforum.org/cms/174-igf-2014/transcripts/2059-2014-09-04-ws69-payment-privacy-policing-paradox-room-4
Manu Sporny: Here's the video from the workshop: 
  https://www.youtube.com/watch?v=m8cIYzy5MIA
Manu Sporny:  We'll put together a page with that info so when 
  talking to governments, standards orgs, etc. we can point to the 
  page.
Manu Sporny: We discussed this stuff on the Credentials CG call 
  yesterday, so we won't rehash that discussion here: 
  http://opencreds.org/minutes/2014-09-09/#5
Manu Sporny:  There's the in depth talk about the workshop (link 
  above).
Manu Sporny:  We'll do followup and try to get those people into 
  the work.

Topic: Payment Initiation / Wallet Use Case Revisions

Dave Longley is scribing.
Manu Sporny: Wallet / Payment Initiation use cases: 
  https://www.w3.org/community/webpayments/wiki/UseCases
Manu Sporny: Last time we talked about this one - Use Case: A 
  merchant advertises different details, such as price, for an 
  offer of sale based on potential payment processor choice.
Manu Sporny:  We ended on Michael Williams' comments, basically 
  saying that we don't think we can achieve what he wants, even 
  though we really want to. [scribe assist by David I. Lehn]
Dave Longley:  We've had discussions about this in the past, the 
  ability to do decentralized clearing. Ripple is an option. We've 
  also talked about using a more decentralized version of the block 
  chain technology.  The key issue is that we need some way to 
  "validate" monetary inputs into the system. [scribe assist by 
  David I. Lehn]
Manu Sporny:  This is all experimental technology, that's the 
  problem. We don't have enough experience w/ it to think about 
  standardizing it because we're not sure it scales. [scribe assist 
  by David I. Lehn]
Timothy Holborn: A project is emerging entitled bitmark 
  https://github.com/project-bitmark/documents/tree/master/pdf 
  perhaps we could ask them whether some technology might exist as 
  to provide that type of service.
Timothy Holborn:  I'm not sure if the way bitmark is implemented 
  supports that or if it can be effectively forked to achieve the 
  needs of web payments
Timothy Holborn:  In melvin's web credits system he has a 
  decentralized blockchain that was working off of data.fm. I 
  believe it was.
Timothy Holborn: http://webcredits.data.fm/
Timothy Holborn: Is it closer to 
  http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf ??
Manu Sporny:  I don't think it was a decentralized block chain, 
  you could put it anywhere, but you couldn't fork the block chain, 
  the fundamental design we're talking about is different from 
  centralized block chain stuff, his stuff would allow you to put 
  the block chain somewhere on the web and everyone would have to 
  agree to a particular history, it was each account gets its own 
  block chain
Timothy Holborn:  Would this be helped if there was some sort of 
  credentialing system?
Manu Sporny:  There's certainly a creds part to it, the URL/HTTP 
  part is used for looking up where a particular resource is, the 
  thing we've been vacillating between is using URL or some 
  decentralized/dht system like telehash to create those URLs.
Manu Sporny:  Using URLs only as an entry point into the 
  decentralized credential/block chain to do reading/writing
Manu Sporny:  We have all these techs up in the air, if we want 
  to make quick progress we can't make the decision to standardize 
  telehash or some decentralized mechanism, we have to use techs 
  that already exist, URLs, JSON-LD, IC, etc.
Timothy Holborn:  It sounds like it's in an experimental field, 
  it's something we're interested in but we don't want to steer 
  away from critical path, it's where innovation can happen and we 
  can participate in some way
Manu Sporny:  I agree, that's the response to Michael we want to 
  have, we agree with him, we want to do what he's talking about 
  but we need the tech to get there.
Manu Sporny:  He even pointed to the decentralized settlement 
  process we have in one of our specs, but he probably doesn't know 
  that's really experimental, we just haven't had the time to work 
  on it
Timothy Holborn:  I think bitmark has 20 active devs on the 
  project, i've spoken to Mark, and he's shown interest in web 
  payments
Timothy Holborn:  They may be interested in participating in the 
  CG
Timothy Holborn:  Maybe we can get them involved w/o having them 
  be a constituent of our critical path
Manu Sporny:  Yes, sounds great, i say that having no real view 
  into technical details of bitmark yet, but if you think it would 
  be good to look at, bring them in
Manu Sporny:  Jorge is saying he doesn't know if a website could 
  display a proper price. The problem is that since the person 
  hasn't specified who their payment processor is, on the website, 
  the website has no way of running the code for showing them the 
  actual price.
Manu Sporny:  We could have some kind of API in the browser for 
  dealing with multiple offers
Dave Longley:  Right now, the merchant can enumerate different 
  offers. The merchant can figure out how to display it. [scribe 
  assist by Manu Sporny]
Timothy Holborn: Description of Bitmark: 
  https://twitter.com/ProjectBitmark/media
Timothy Holborn: In images.
Manu Sporny:  Anything else on the use case before moving on?
Timothy Holborn:  Nope

Topic: Loyalty Cards

Manu Sporny: Next use case - Use Case: A buyer can associate a 
  membership card, coupon, or similar token with a transaction to 
  receive a discount or other benefits.
Manu Sporny: Steven Rowat said - I think these could wait until a 
  later version. I know many marketing strategies use them, but 
  many don't; essentially they're an optional add-on (IMO there's 
  an argument that they're like tariff barriers -- somebody starts, 
  then everybody does it, and it becomes cruft that we all pay for 
  without good reason). I suggest putting minimal resources into 
  it, as a socket that the vendor must provide most of the 
  code/structure for. 
Manu Sporny:  What we could do is push this off to the creds 
  group ... having a loyalty coupon/membership is like having a 
  credential
Timothy Holborn: +1
Manu Sporny:  When you try to do a purchase a vendor could 
  optionally ask for a loyalty credential
Manu Sporny:  And then the vendor could price accordingly
Manu Sporny: Adrian also said that he'd prefer to have this for 
  later iterations.
Timothy Holborn:  I agree, i would just ask if that credential 
  could be used to provide the discount in the transactional 
  process
Manu Sporny:  The way it would work, i think with the current 
  tech, there would be a request for the loyalty card, then the 
  website would show a different set of offers
Dave Longley:  We can certainly do it the way that you just 
  suggested. I can't think of a hook that a payment processor could 
  use to process that. [scribe assist by Manu Sporny]
Dave Longley:  Payment processor looking at a set of payees, this 
  other information is present (like a loyalty coupon), it's not 
  built into the transaction process. The merchant probably 
  establishes that you have the loyalty card through the 
  credentials process. [scribe assist by Manu Sporny]
Timothy Holborn:  This doesn't affect the digital receipt, right? 
  [scribe assist by Manu Sporny]
Dave Longley:  The vendor can always include extra information in 
  the digital receipt, to say that they used a loyalty card, but 
  the payment processor will not know about that information (most 
  likely) [scribe assist by Manu Sporny]
Dave Longley:  There would be no special processing rules that 
  the payment processor could apply to the loyalty card info, but 
  the vendor could include it and get that information back in the 
  receipt
Dave Longley:  (It would be opaque to the payment processor)
Dave Longley:  In the future, if a certain token is present in an 
  offer, then a different set of payees could be used. If we think 
  it's beneficial to be put into the transaction process. [scribe 
  assist by Manu Sporny]
Dave Longley:  There will be some details about ensuring that the 
  information remains private - loyalty cards can't be misused. 
  [scribe assist by Manu Sporny]
Timothy Holborn:  I think there is a use case to have a social 
  membership card
Timothy Holborn:  And that's also a credentials problem
Manu Sporny:  Yeah, i think whenever we're talking about 
  membership i think that's a credentials thing that we can push 
  off to that group
Manu Sporny:  Until there's a very solid use case that says this 
  loyalty coupon/membership card absolutely must be part of the txn 
  process we should leave it out and let people just compose the 
  two techs: creds and payments together to solve these complex use 
  cases
Manu Sporny:  Rather than complicating the payment protocol

Topic: Variable Pseudo-anonymity

Manu Sporny: Next use case is - Use Case: Leveraging variable 
  degrees of anonymity per requirements of the payment transaction.
Manu Sporny: Feedback from Adrian is to shift this to a later 
  version.
Manu Sporny:  Based on the discussions we've been having, 
  especially about the nigerian ID card, kingsley and steven 
  rowat's input on that, i don't think that the variable degrees of 
  anonymity and privacy we can shift this to a later version ... 
  people seem to be rightly concerned about this issue
Timothy Holborn:  Is this a creds use case?
Manu Sporny:  Kind of, if you have an account that is identified 
  by some URL and that URL can be used to discover who you are and 
  get some info about you, then that's problematic, without even 
  talking about the creds stuff, but if your URL has "timholborn" 
  in it then people can identify who you are, or based on your 
  spending habits at two sites owned by the same org, if you 
  transmit a pseudo-anonymous cred and you name/whatever is in the 
  account URL then your ID is less than you think.
Manu Sporny:  You shouldn't have to transmit your entire ID if 
  you're just buying a candy bar
Timothy Holborn:  I absolutely agree i just thought creds would 
  be handling this?
Manu Sporny:  It could be, there are two chunks of info 
  transmitting to the website, you notify the website who your 
  payment processor is (and that's it) and they don't know who you 
  are, if when the digital receipt is generated and the payment 
  processor puts in there, say your name in a URL, then your 
  privacy is violated because the payment processor didn't know you 
  were doing something pseudo anonymous
Manu Sporny:  And so that info gets accidentally leaked.
Timothy Holborn:  Makes sense, I agree.
Timothy Holborn:  I think the language should be clearer -- 
  defining pseudo-anonymity, etc.
Manu Sporny:  I think that we should use pseudo-anonymity 
  everywhere
Timothy Holborn:  Yes, you said the tech isn't there for true 
  anonymity
Timothy Holborn:  I think we should state some defs for anonymity
Scribe missed some fast discussion on anonymity.
Manu Sporny:  I think there's a lot of confusion on what 
  anonymity means, using cash isn't anonymous, serial numbers on 
  cash, etc.
Timothy Holborn:  Video cameras in the building
Dave Longley:  Merchant saw your face
Manu Sporny:  When we talk about true anonymity it's something 
  like a usb drop cemented into an alleyway w/ no cameras for 
  multiple blocks around.
Manu Sporny:  We need to be more clear and use pseudo-anonymity 
  from here on out so people don't think they are more protected 
  than they are
Manu Sporny:  Whatever your definition of anonymity is, you may 
  not be as private/safe as you are
Manu Sporny:  If you're that worried about it you shouldn't be 
  doing it over the internet
Manu Sporny:  The internet makes it easy to find "the" node to 
  send information to... and then it's easy to track that 
  particular node
Timothy Holborn:  I believe lay technical people believe things 
  like 'Bitcoin provides true anonymity' and that's misleading and 
  unfortunate, from a marketing level it's difficult to clarify, 
  between one org that claims anonymity and one that claims 
  pseudo-anonymity, i think integrity of this process is of utmost 
  importance.
Manu Sporny:  We're not against true anonymity per se but it 
  would be completely incorrect to say we provide it
Timothy Holborn:  I'm a citizen of Australia and if i'm being 
  investigated that much then so be it. I think people that are 
  super afraid of that maybe shouldn't be on the Web.
Evgeny Vinogradov:  Maybe we can achieve true anonymity in this 
  use case, the buyer can be completely anonymous to merchant but 
  provide details to merchant.
Timothy Holborn: What i was saying, was that as a subject to the 
  rule of law (of my country, Australia) then if lawful intercept 
  makes requests - so be it.  Yet, there are so very many use-cases 
  where people have the right to pseudo-anonymity.
Dave Longley:  We should still be careful about using "true 
  anonymity". It's just a higher degree of anonymity. If a merchant 
  uses sophisticated tracking techniques, the buyer could be 
  tracked. [scribe assist by Manu Sporny]
Timothy Holborn: Almost every other party; save, local 
  law-enforcement, etc.
Manu Sporny: For example, putting a Google tracking cookie would 
  allow Google to figure out who a buyers is.
Manu Sporny:  Any kind of tracking cookie from any org or 
  conglomerate could allow them to follow browsing habits and 
  figure out who a person is
Timothy Holborn:  Or a browser login, etc.
Manu Sporny:  There are so many different ways to track people 
  online, while we can solve the pseudo-anonymity problem between 
  buyer and merchant ... that doesn't mean cookie tracking, 
  malware, etc. lots of other devices don't exist that errode your 
  privacy online (all out of scope for the work here)
Manu Sporny:  We're just trying to increase the level of effort 
  any org would have to extend to violate your privacy, we're not 
  saying it's impossible just making it as difficult as we can to 
  break privacy
Timothy Holborn:  The gov't is of service to the people, and what 
  they provide is very different from what a private corporation

Topic: Offers and Price Quotes

Manu Sporny: This is the next one - Use Case: A buyer discovers 
  an offer for sale by a merchant under terms that the merchant is 
  comfortable with. The offer includes a list of payment processors 
  that the merchant is capable of receiving payment through. The 
  buyer's software contacts a subset of those payment processors 
  that they are capable of sending payment through to get finalized 
  transaction details (such as price or speed) before executing the 
  most desirable transaction.
Manu Sporny: Jorge's feedback - NASCAR problem
Dave Longley:  Again, I think that's a misunderstanding of the 
  NASCAR problem. This is about user choice, not about splattering 
  choices that are not relevant to the buyer. This is about giving 
  the buyer choice. This is about providing the buyer with utility, 
  not noise. [scribe assist by Manu Sporny]
Manu Sporny: Feedback from Michael Williams: Is there a user flow 
  for proxying from payment processors included by merchant to 
  another payment processor as described above?
Dave Longley:  We should at least mention the decentralized 
  payment processor/proxied payment processor idea as a design 
  criteria for a future version or similar so it's on the IG's 
  radar

Topic: Native App Purchases

Manu Sporny: Next Use Case: A buyer uses a native non-browser 
  application on their mobile phone or tablet, or a web browser to 
  make a purchase at an app store.
Manu Sporny: Jorge's feedback: Native apps are ok as long as they 
  use the Web infrastructure for the transactions (e.g. REST APIs)
Timothy Holborn: +1
Dave Longley: +1
Manu Sporny:  Anything else to discuss before next call?
Timothy Holborn:  The creds group is working on some of the use 
  cases for identity, if there's any feedback from web payments 
  group that would be great
Timothy Holborn:  Any other use cases they suggest, etc.
Manu Sporny:  I think we have to be very careful with how we 
  reword the use cases in the creds group, some will be fundamental 
  for creds and others will be periphery use cases web payments 
  people care about
Received on Wednesday, 10 September 2014 20:36:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:39 UTC