Web Payments Telecon Minutes for 2014-06-10

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

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0039.html
Topics:
  1. US Federal Reserve Meeting
  2. Identity Credentials Proof of Concept
  3. Registration-less Purchases
  4. Scalable Whitelisting
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, Pindar Wong, David I. Lehn, Timothy 
  Holborn
Audio:
  https://web-payments.org/minutes/2014-06-10/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Additions to the Agenda: We should add two things 
  to the agenda, one is the Identity Credentials demo and the other 
  is the meeting with the US Fed tomorrow that's part of the 
  extension of the work we started with them at the Paris workshop. 
  Any other additions?
Pindar Wong: None from me.
David I. Lehn: Nope.

Topic: US Federal Reserve Meeting

Manu Sporny:  Tomorrow i'm headed to the US Fed bank in Kansas 
  City, we've made good contacts with the US Fed, they are very 
  interested in sending someone to join the web payments work
Manu Sporny:  They are making sure they have someone assigned to 
  us
Manu Sporny:  So we have solid contacts in the US Fed now.
Pindar Wong: Please keep in view regulatory FinTech evolution 
  from others jurisdictions such as in Asia Pac
Manu Sporny:  As a result of that we should be able to get in 
  front of a lot of banks and financial institutions, mainly 
  because the US Fed has said that they are really pushing forward 
  to make payments faster and more secure in the US and they are 
  looking for different ways to do it both in and outside the 
  financial industry and the web payments work is somewhat outside 
  it so they are interested in what we're doing here.
Manu Sporny:  We'll be meeting with some of the people we'll be 
  directly working with on the web payments stuff.
Manu Sporny:  Any questions on that upcoming meeting?
Pindar Wong:  None

Topic: Identity Credentials Proof of Concept

Manu Sporny: Background on this topic is here: 
  http://manu.sporny.org/2014/identity-credentials/
Pindar Wong: Haven’t had time to do a decent first pass. Comments 
  thus far looks encouraging. I will need about 2 days
Manu Sporny:  If you've been tracking the mailing list, finally 
  we were able to send out and release all the source code for a 
  demo on identity security and Identity Credentials, it has to do 
  with some of the stuff we're going to be talking about at IGF in 
  Turkey later this year
Manu Sporny:  What we release is what we believe to be a fairly 
  fully-designed solution for doing high-stakes credentials on the 
  web, if you need to prove who you are to a website, if you need 
  to transmit a gov't issued ID card, or whether you are over the 
  age of 18, 21, 55, 65, etc. if you want to transmit some gov't 
  security clearance ... or something as simple as your shipping 
  address, email address, phone number, the demo we just released 
  outlines how you do that in a decentralized way
Pindar Wong: You *do* realize that this is *the* question to try 
  to solve. Now we need to verify the Internet dog’s name in a 
  distributed way. 
Manu Sporny:  Now someone can own all of the credentials that are 
  associated with their identity and send them on an as needed 
  basis, it's in the same ballpark as OpenID Connect, we hope it's 
  much more secure, decentralized, and privacy-aware than the other 
  solutions out there
Manu Sporny:  We're putting this out there to get the 
  conversation going on how we think the solution should work
Pindar Wong: We should update the IGF website to point to this 
  and find a mechanism to get this outthere to start the dialogue 
  in advance of the Istanbul meeting
Manu Sporny:  This has a lot to do with payments because to do 
  high-value payments you need KYC, customer clearing, 
  anti-laundering, etc.
Manu Sporny:  We have 10 days to do that [what pindar is saying]
Pindar Wong: Great thanks!
Manu Sporny:  My focus is getting the IGF proposal in shape and 
  getting the people invited
Timothy Holborn:  People looking at this at different ways 
  [missed] ... JSON-LD, turtle, [missed] is another big one, i 
  think that there's a feeling that [missed] that technology 
  [missed] to secure a person's status
Manu Sporny:  I think there's a misunderstanding where WebID+TLS 
  fits in with Identity Credentials, they are interoperable at the 
  most basic level
Timothy Holborn: Might type it: these crediential systems; can 
  support RWW systems...
Timothy Holborn:  I agree with you
Timothy Holborn:  There are two factors in there
Timothy Holborn:  There are two factors, one is that FOAF 
  represents an agenda, i interpret as a persona or person... this 
  maps to a WebID TLS cert, which doesn't denote what the basis of 
  that relationship [missed] ... where you are storing all the data 
  on your web server, for example, one of the benefits i saw 
  immediately, was that the IC system was quite clearly indicating 
  a legal statement about a person, i think that's relevant
Timothy Holborn:  What i can gather is that if i want to set up 
  [missed], if i want to sync all my own apps [missed], [missed 
  echo], worldwide i can do whatever i want, it's mine ... and the 
  data that i store is a decision i make [missed], the IC tech 
  seems to communicate that very well, not only does that 
  communicate that with a Web ontology, it makes it possible to 
  verify those facts, at the end of the day i validated that 
  service,  here's my passport, it's only validated for me, 
  [missed], the framework ...
Timothy Holborn: Essentially; i’m saying identity credientials; 
  states clearly who is the owner of the crediential
Timothy Holborn: The ability to create ‘persona’ perahps using 
  FOAF documents; attached to a real identity - seems like what is 
  needed for RWW
Manu Sporny:  Let's continue the discussion on the mailing list, 
  i think most people are aligned
Timothy Holborn: +1
Dave Longley:  What Tim said was that identity credentials are 
  more clear that you're talking about a particular person. [scribe 
  assist by Manu Sporny]
Timothy Holborn: +1 Essentially...
Timothy Holborn: It’s clear about the legal entity that is being 
  defined
Pindar Wong: Let’s take it to the list. One problem might be what 
  data is considered’ free game’ in the Public Domain (like one’s 
  name) 
Pindar Wong: This will make the iGF discussion productive and 
  tangibly meaningful
Manu Sporny:  In any case, i think we're good, i think what we 
  have out there is a proof of concept, we'll need to discuss in 
  more detail, and see what people like and where we are aligned, 
  it took us too long to get it out there but we were busy and we 
  felt we needed to get something out there to ground the 
  discussion because anders and some other didn't understand how 
  identity played into this
Manu Sporny:  This is an attempt at getting this out there to say 
  what identity and credentials are out there and important and now 
  with some grounding we can discuss it, it will be confusing over 
  the next couple of weeks but now it's done and it helps 
  w/discussion
Manu Sporny:  This makes it more tangible so people don't think 
  we're just talking theory
Manu Sporny:  We have an implementation
Pindar Wong: YES! :)
Manu Sporny:  We can point and say "this is what we're talking 
  about"
Timothy Holborn: I’m really very impressed with the solution; 
  however believe that it is important for the developer community 
  to see how this POC can work with RWW 
Manu Sporny:  "So can we get some feedback"
Manu Sporny:  We can have the rest of the discussion on the 
  mailing list
Timothy Holborn: :)
Pindar Wong: :)

Topic: Registration-less Purchases

Manu Sporny:  The idea here is that people should be able to join 
  [visit?] a website and without having to enter your shipping 
  info, username, etc. .. we want people to go to a site and click 
  buy and finish the purchase without having to create an entire 
  account on the site
Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
Manu Sporny: What we have right now is this: Make it simple to 
  register as a new customer (get rid of the registration step, if 
  possible, or make it transparent).
Dave Longley:  So, we need to change some of this text to make it 
  a use case [scribe assist by Manu Sporny]
Dave Longley:  A user joins a website and makes a purchase 
  without having to register an account. [scribe assist by Manu 
  Sporny]
Dave Longley:  A user goes to a website and makes a purchase 
  without having to register an account. [scribe assist by Manu 
  Sporny]
Timothy Holborn: Could be sending a micropayment like ‘tipjar’
Dave Longley:  If you're buying something that doesn't have any 
  age requirements, and is a digital good, you would probably not 
  need to transmit much of anything, maybe just the identity URL. 
  [scribe assist by Manu Sporny]
"Use Case: Transact with a merchant without revealing any 
  identifying information. Identifying information is available to 
  the payment processor."
Timothy Holborn: +1
Pindar Wong: Nice
Pindar Wong: +1
Dave Longley:  We already have that as a use case. [scribe assist 
  by Manu Sporny]
Timothy Holborn: Is the difference between the two; about the 
  ability to simply buy the goods, and not create a ‘loyalty 
  relationship'..
Dave Longley:  So, you might still send them information, but you 
  don't have to send them information as a part of the purchase 
  process. [scribe assist by Manu Sporny]
Pindar Wong: I should have mentioned this earlier but please keep 
  in view the Creative Commons community w.r.t. the proof of 
  concept
Timothy Holborn: Great note...
Dave Longley:  You don't have to go through a process where you 
  establish an account on this site. That's really what this use 
  case is about. You're able to make the purchase without creating 
  that "loyalty use case". [scribe assist by Manu Sporny]
Dave Longley:  Whether or not the merchant wants to store 
  anything about their identity should not be of concern to the 
  customer. [scribe assist by Manu Sporny]
Timothy Holborn: Two parts of creating an account (traditionally) 
  for websites. 1. fulfillment requirements - tracking the order 
  (could be done via a URI, stored on a RWW server elsewhere); 2. 
  creating a loyalty relationship
Manu Sporny: Right, so we don't want to do #2 above (in this use 
  case), just #1
Timothy Holborn: Traditionally data is stored within the site’s 
  CMS.
Dave Longley:  The customer doesn't have to register or 
  acknowledge that any account has been created. They can fulfil 
  their purchase without having to do any of that. [scribe assist 
  by Manu Sporny]
Timothy Holborn: To store transaction details in a distributed 
  way as to support the forfillment of a transaction without 
  requiring the establishment of a loyalty relationship
Timothy Holborn: I think that’s user-definable.
Timothy Holborn: A user may select a ‘persona’ in which to 
  present identity (for loyalty purposes) to the merchant.
Timothy Holborn: If the user decides to use the same persona - 
  then the merchant can track it
Dave Longley:  The customer goes to a merchant website and clicks 
  a buy button and completes the purchase without having to go 
  through any registration process. They also don't have to 
  remember any information to buy anything else on the website and 
  the merchant will be able to remember the customer when they 
  return to the website (via some unique identifier associated with 
  the customer) [scribe assist by Manu Sporny]
Dave Longley:  Tim said, you could have a single identity 
  document with multiple personas associated with it, identifiers 
  that are credentials, and you could share different credentials 
  w/ the merchant. You chose what to release to track their 
  purchasing behavior. [scribe assist by Manu Sporny]
Timothy Holborn: "A user may select a ‘persona’ in which to 
  present identity (for loyalty purposes) to the merchant"
Timothy Holborn: I think the implicit requirement is that the 
  identifier is a URI; not a database entry of a customers details 
  (primarily)
Timothy Holborn: +1
Manu Sporny: The customer goes to a merchant website and clicks a 
  buy button to complete a purchase without having to go through 
  any registration process. During the purchase the customer 
  chooses which information to share with the merchant which the 
  merchant then uses to uniquely identify the customer if they 
  perform any repeat purchases.
Timothy Holborn: +1

Topic: Scalable Whitelisting

Manu Sporny:  Scalable whitelisting came about as part of the 
  Mozilla payments stuff
Manu Sporny: This is what we have right now: Whitelisting of 
  parties - users, merchants, payment providers without scalability 
  / anti-compete issues.
Manu Sporny:  The way mozilla ended up implementing their 
  payments API in the first iteration was that they just 
  whitelabeled the companies that could initiate the payments 
  UI...clearly taht does not sclae
Manu Sporny:  You can't have the browser manufacturers, google, 
  paypal, etc. deciding who gets to use the payments API and who 
  doesn't
Manu Sporny:  The counter-argument is that if you open up this to 
  anyone, you end up with phishing/criminal sites taking advantage 
  of people
Manu Sporny:  Discussions about mitigating that ... make sure 
  payments UI is user initiated, but even that can be phished, etc.
Manu Sporny:  We came up with one proposal initially, which was 
  that when you go with a payments service, you can have an API 
  that allows that service to register as a payments provider, then 
  that provider has to be used you can't just guess who the 
  customer's payment provider is
Manu Sporny:  So the site you go to when you try to make a 
  payment is set in the browser
Manu Sporny:  We would have a whitelist of all the payment 
  providers that you have said previously that you're ok to do 
  payments through
Manu Sporny:  Mozilla was pretty adamant about the whitelisting 
  service as it would prevent a lot of fraud for them
Timothy Holborn: Many  of these sorts of issues relate to 
  identity
Manu Sporny:  We don't know what the full fraud ramifications are 
  for the tech ... because we don't know what the tech will be, we 
  are just going for use cases, we don't know what the final thing 
  will be
Manu Sporny:  All that to say is that we can't easily say exactly 
  what this whitelist should be or if we even need it
Timothy Holborn: X509 certs 
Dave Longley:  Let's talk about what this particular use case is 
  about... make sure a user trusts a payment processor. Make sure 
  it's a payment processor that they trust and has been someone 
  that they've previously registered with. [scribe assist by Manu 
  Sporny]
Timothy Holborn:  From a user perspective, the way WebID+TLS 
  functions is providing distinguishable [missed] documents into 
  [missed] one of the simple [missed] would be whether or not the 
  [missed] has a relationship to the user [missed]
Timothy Holborn: WebID-TLS creates a user certificate, with a 
  subjectAltName URI
Timothy Holborn: If that URI described a machine, with a 
  location; 
Timothy Holborn: And the identity linked to that certificate - as 
  a known entity.
Manu Sporny:  I think this use case has more to do with the 
  customer trusting the payment processor rather than the merchant 
  trusting the customer
Manu Sporny:  I think this case has more to do with whether or 
  not you trust the merchant you're going to do business with or 
  the payment processor you're going to do business with 
Manu Sporny:  The thing Mozilla was concerned with was "how do 
  you trust the dialog that asks you to pay"
Manu Sporny:  To ensure it's coming from your payment processor, 
  not something trying to steal your information
Timothy Holborn: I imagine the merchant’s certificate might 
  distinguish the claim?
Timothy Holborn: Mind; use-case, not iterative method...
Timothy Holborn: So; what’s the use-case.
Manu Sporny:  [Missed] merchant certificate might have problems 
  for a single domain with lots of merchants (eg: ebay)
Timothy Holborn: Gets tricky.  lots of applications...
Manu Sporny:  I think this use case has to do mainly with making 
  sure that the UI you're looking at is from your payment processor
Timothy Holborn: Sounds reasonable....
Timothy Holborn: The classic example might be the spam email you 
  get from ‘your bank'
Timothy Holborn: This goes to the legality of the transaction.  
  It’s an identity use-case
Timothy Holborn: Also goes to intention.  did the parties intend 
  to make a transaction with each-other for the specified amount, 
  upon the specified tersm
Timothy Holborn: Terms
Timothy Holborn: Is this the ability to provide a secured payment 
  claim from a known entity.
Manu Sporny: So the use case is: A customer goes to a website and 
  is presented with a payment UI from their payment processor. The 
  UI is displayed in such a way as to guarantee that there is no 
  information that can be phished from the customer.
Timothy Holborn: Consent from a trusted source
Manu Sporny: So the use case is: A customer goes to a website and 
  is presented with a payment UI from their payment processor. The 
  purchase can be completed without any additional information from 
  the customer other than their consent to complete the purchase.
Timothy Holborn: So - you present me with a payment claim
Timothy Holborn: My system comes-up, says you’ve got a payment 
  claim.  
Timothy Holborn: Did i intend to pay you.
Timothy Holborn: I agree.
Timothy Holborn: Vs. 
Timothy Holborn: You have website
Timothy Holborn: Your website says, pay me.
Timothy Holborn: Perhaps i still don’t know the real owner of the 
  website.
Dave Longley:  This use case isn't about whether or not you trust 
  the merchant... it's about whether or not you trust the dialog 
  presented by your payment processor. [scribe assist by Manu 
  Sporny]
Timothy Holborn: +1
Manu Sporny: Ok, so we're using this: A customer goes to a 
  website and is presented with a payment UI from their payment 
  processor. The purchase can be completed without any additional 
  information from the customer other than their consent to 
  complete the purchase.
Dave Longley:  And the reason is that we don't want the merchant 
  to phish any secret information from you.  [scribe assist by Manu 
  Sporny]
Manu Sporny: Ok, that's all the time we have for today. Thanks 
  for the call everyone, we'll chat next week.

Received on Tuesday, 17 June 2014 20:59:21 UTC