Web Payments Telecon Minutes for 2014-05-14

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-05-14/

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

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014May/0059.html
Topics:
  1. Payment Links
  2. Identity Verification and Trust
  3. Reputation Systems
  4. 3rd Party Signed Digital Credentials
  5. Password-less identity solution
  6. OpenID Connect-based payment initiation
  7. Separation of Privacy and Anonymity
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, David I. Lehn
Audio:
  https://web-payments.org/minutes/2014-05-14/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Any items to add to the agenda?
No additional items.
Manu Sporny:  Ok, then we'll be dealing with the section on 
  Identity today: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Identity

Topic: Payment Links

Manu Sporny: The first use case is: Invoke payment service via 
  URI scheme. Simple URI system - simple payment markup that 
  developers get right.
Manu Sporny:  This was proposed by Yandex at the web payments 
  workshop, they wanted a simple URL for users to click on to 
  initiate a payment
Manu Sporny:  We did some of this work a while ago with the 
  payment links spec
Manu Sporny: This was the work we did before: 
  https://web-payments.org/specs/source/payment-links/
Dave Longley:  There is also work on custom protocols, they can 
  register w/ it - triggers payment processor to take over. [scribe 
  assist by Manu Sporny]
Manu Sporny:  One thing we could do is specify what the url 
  format is
Manu Sporny:  And then what happens when multiple people register 
  for the same handler
Dave Longley:  You can register a protocol handler to handle the 
  link. It's not clear whether this is already a solved problem or 
  not. Seems like it is w/ protocol handlers. [scribe assist by 
  Manu Sporny]
David I. Lehn:  At some point i did a demo for this
Manu Sporny:  Ok so that's in there, we accept the use case

Topic: Identity Verification and Trust

Manu Sporny: We currently have this use case - Verify identity or 
  assess trust of partners in a transaction.
Manu Sporny: That probably should be: Transmit one or more pieces 
  of information that can be used to identify a participant in a 
  transaction.
Dave Longley:  The use case seems ill-defined - does the 
  transmission happen when you initiate the transaction?  [scribe 
  assist by Manu Sporny]
Dave Longley:  Does it happen after-the-fact? So you can 
  follow-up via the digital receipt? [scribe assist by Manu Sporny]
Dave Longley:  Does this happen before or after the transaction? 
  [scribe assist by Manu Sporny]
Manu Sporny:  We could split into two use cases
Manu Sporny:  One is transmit before, other is figure out via 
  digital receipt
Manu Sporny: So, what about this: Transmit one or more pieces of 
  information before a purchase occurs such that the identification 
  of participants in a transaction can be performed.
Manu Sporny: And then we'd have another one: Using metadata that 
  is the result of a transaction, discover the verified identity of 
  participants in the transaction.
Manu Sporny: Then, wrt. trust, we have this one: Assess the 
  trustworthiness of an entity before entering into a particular 
  transaction with the entity.
Dave Longley:  Thinking through blockchains and other 
  technologies that could be used to achieve this. For example, the 
  transaction is recorded, but not accepted until you decide to 
  trust the individual (counter-signatures). [scribe assist by Manu 
  Sporny]
Dave Longley:  If these are digitally signed receipts, you trust 
  the key, you trust the receipt. This could be in scope. [scribe 
  assist by Manu Sporny]
Manu Sporny: I thought the trustworthiness thing would be more 
  like an eBay-like rating system.
Dave Longley:  In some cases it's in-scope, others is out of 
  scope. Rating system is out of scope. However, trusting the 
  identity/key is something that's in scope. [scribe assist by Manu 
  Sporny]
Dave Longley:  This use case is too open to interpretation as to 
  what that means. [scribe assist by Manu Sporny]
Manu Sporny:  We have another use case with reputation system 
  mentioned
Dave Longley:  Ok, let's just strike this and use that

Topic: Reputation Systems

Manu Sporny: What we have for this currently is: Merchant and 
  User reputation system accessible to the payments system.
Manu Sporny: This seems out of scope for the first revision, and 
  could be added later via a Linked Data mechanism.
Dave Longley:  Yes, agreed, this seems out of scope. [scribe 
  assist by Manu Sporny]
Manu Sporny: Ok, moving this to out of scope in the use cases 
  document.

Topic: 3rd Party Signed Digital Credentials

Manu Sporny: We have this use case currently - Digital 
  credentials that can be used for financial transactions, that 
  provide plausible deniability to payment processors
Manu Sporny: ("We vetted the customer and they lied to us in a 
  sophisticated way, here's proof").
David I. Lehn:  Why is it phrased that way?
Manu Sporny:  This is verbatim what was typed at the workshop
Manu Sporny:  The scribe typed whatever was being said
Manu Sporny: What about this? Digitally verifiable credentials 
  such that a merchant or payment processor can prove that they 
  have done due diligence when entering into a financial 
  transaction with a customer.
David I. Lehn:  It's any party in a transaction. [scribe assist 
  by Manu Sporny]
Dave Longley:  If we say 'legal' - we may broaden the scope too 
  much. This is about getting 3rd party proof of the people 
  involved in the transaction being who they are (or they've stolen 
  credentials). You made a best effort to confirm who they say they 
  are. [scribe assist by Manu Sporny]
Manu Sporny: Ok, then this? Digitally verifiable credentials such 
  that any participant in a transaction can prove that a 3rd party 
  has certified particular attributes of each participant in the 
  transaction.
Dave Longley:  We should probably say "trusted third party" 
  [scribe assist by Manu Sporny]
Dave Longley:  Aspects of this use case are in scope, others are 
  not. [scribe assist by Manu Sporny]
Dave Longley:  It might be out of scope to cover it for the 
  user's case (difficult or unnecessary to do that). Currently, TLS 
  is a good-enough trust system to verify their payment 
  processor/merchant. It would be nice for this to be covered in 
  the user's case as well, but there might be a lot of scope creep 
  there. [scribe assist by Manu Sporny]
Dave Longley:  It's important that we cover it for at least the 
  customer. The person that is transferring value, that's the 
  primary participant in this use case. We don't want them 
  acquiring value from a merchant w/o having paid for it. [scribe 
  assist by Manu Sporny]
Manu Sporny: Ok, so this: Digitally verifiable credentials such 
  that a merchant and payment processor in a transaction can prove 
  that they have done due diligence in verifying the customer's 
  identity (KYC).
Dave Longley:  That's good

Topic: Password-less identity solution

Manu Sporny: So, we have this right now - Identity solution must 
  not rely on passwords for primary functionality.
Dave Longley:  It's very unclear what primary functionality is
Dave Longley:  We need to define it... and we can't get rid of 
  passwords. That doesn't mean that they need to provide that piece 
  of information at every point where their identity needs to be 
  confirmed. We don't want them to give that secret passphrase to 
  every place they do business. [scribe assist by Manu Sporny]
Dave Longley:  We want to get them to some other security 
  protocol where they should not use a password, like PKI. [scribe 
  assist by Manu Sporny]
Dave Longley:  We just need to be more specific about what 
  primary functionality means. Users only need to rely on passwords 
  with their identity providers, they don't use those passwords 
  anywhere else, they use PKI (or something equivalent). [scribe 
  assist by Manu Sporny]
Dave Longley:  User's should not have to share their secrets w/ 
  merchants, unless the secret is absolutely vital for the 
  transaction taking place (like your home address to ship a 
  product to). [scribe assist by Manu Sporny]
Dave Longley:  This is about an identity solution that minimizes 
  the number of secrets you need to share w/ various parties. 
  [scribe assist by Manu Sporny]
Manu Sporny: So, what about: Execute a transaction without 
  revealing secrets (i.e. identity, passwords, credit card numbers, 
  PINs) whose primary purpose is orthogonal to the actual 
  transaction.
Dave Longley:  The secrets that are revealed during these 
  exchanges should not be able to be re-used such that they create 
  an unnecessary amount of damage to the customer. [scribe assist 
  by Manu Sporny]
Manu Sporny:  If they have a passport or SSN, etc. they can use 
  that in another system that isn't as secure to take advantage, so 
  still lots of possible damage
Manu Sporny: So, maybe change to this: Execute a transaction 
  without revealing secrets (i.e. identity, passwords, PINs) whose 
  primary purpose is orthogonal to the actual transaction.

Topic: OpenID Connect-based payment initiation

Manu Sporny: We have this now - Use OpenID Connect to bootstrap a 
  payments process.
Dave Longley:  We might want to rephrase - whatever digital 
  credential solution should be compatible with existing, widely 
  deployed identity protocols. This is a requirement, not a use 
  case. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so: Use an existing, widely deployed identity 
  provider mechanism (i.e. OpenID Connect) to bootstrap the 
  payments process.
Dave Longley:  Ok, that sounds fine. [scribe assist by Manu 
  Sporny]
Manu Sporny:  "Bootstrap" is vague. [scribe assist by Manu 
  Sporny]
Dave Longley:  You can go from your existing identity solution 
  into this other system, that's what we mean by bootstrap. [scribe 
  assist by Manu Sporny]
Manu Sporny: So, initiate?
Dave Longley:  That makes it sound like there's no intermediate 
  step. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so this? Use an existing, widely deployed 
  identity provider mechanism (i.e. OpenID Connect) to integrate 
  with a digital credentials sharing and payments initiation 
  process.

Topic: Separation of Privacy and Anonymity

Manu Sporny: We have this now, Separate the idea of privacy and 
  anonymity when it comes to web payments.  Privacy for online 
  actions is important.  Anonymity when it comes to financial 
  transactions and moving of money is problematic.
Dave Longley:  It's strange to say "separate the idea" - too 
  abstract. [scribe assist by Manu Sporny]
Dave Longley:  It's not even a use case, the use case would be 
  something like "Protect the privacy of customers when 
  transacting, revealing only the details necessary."  [scribe 
  assist by Manu Sporny]
Manu Sporny: The discussion at the workshop revolved around three 
  things - privacy, discoverability of identity, and anonymity.
Manu Sporny: Privacy had to do with the merchant not being able 
  to discover who you are, but the transaction processor/government 
  being able to investigate (after the fact) if a fraudulent or 
  illegal transaction had occured.
Manu Sporny: The anonymity aspect had to do with a truly 
  anonymous transaction, that was completely untraceable - such as 
  buying a candy bar using cash.
Dave Longley:  Truly untraceable would be a candy bar drop zone - 
  no surveillance. You put a dollar in the box, come back after a 
  day, get your candy bar. [scribe assist by Manu Sporny]
Dave Longley:  Maybe this should be: transact with a merchant 
  without revealing any identifying information. Identifying 
  information is available to the payment processor and government 
  organizations. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so this? Transact with a merchant without 
  revealing any identifying information, however, identifying 
  information is available to the payment processor and government 
  organizations (via a warrant).
Dave Longley:  There are some countries where you don't need a 
  warrant. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so we can strike that, and make it this: 
  Transact with a merchant without revealing any identifying 
  information. Identifying information is available to the payment 
  processor.
Manu Sporny: Ok, so we have another use case that came out of 
  this.
Manu Sporny: Enable fully anonymous transactions such that the 
  identity of the customer is not discoverable
Dave Longley:  No identity, it's out of scope? [scribe assist by 
  Manu Sporny]
Manu Sporny: No, a number of workshop participants made it very 
  clear that anonymous financial transactions were a requirement 
  for them.
Manu Sporny: You shouldn't have to hand over your name when 
  you're buying a candy bar.
Dave Longley:  This has to do w/ tokenization of identity such 
  that it's not traceable - it's a shared token, just one 
  transaction, etc. It's untraceable. [scribe assist by Manu 
  Sporny]
Dave Longley:  The system that's being created here isn't going 
  to record any information, but there may be other systems out 
  there that are capable of tracking who you are (tracking cookies, 
  for instance). [scribe assist by Manu Sporny]
Dave Longley:  We're not doing a purely anonymous transaction, 
  we're not going to add identifying information to the 
  transaction. [scribe assist by Manu Sporny]

Received on Wednesday, 14 May 2014 16:35:39 UTC