Web Payments Community Group Telecon

Minutes for 2014-06-10

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

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.