Web Payments Community Group Telecon

Minutes for 2014-05-14

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]

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