- From: <msporny@digitalbazaar.com>
- Date: Wed, 28 May 2014 13:12:25 -0400
- To: Web Payments CG <public-webpayments@w3.org>
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-28/ 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-28 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014May/0139.html Topics: 1. Is Identity a Distraction? 2. Memorable Payment Identifiers 3. Trusting Short Payment Identifiers 4. Short Payment Identifiers for Donations 5. Loyalty Cards, Tokenization Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Timothy Holborn, Brent Shambaugh Audio: https://web-payments.org/minutes/2014-05-28/audio.ogg Dave Longley is scribing. Manu Sporny: We have some discussion around identity discovery as raised by Evan on the mailing list Topic: Is Identity a Distraction? Manu Sporny: http://lists.w3.org/Archives/Public/public-webpayments/2014May/0128.html Manu Sporny: Evan raised three use cases to talk about with respect to discovery David I. Lehn: Identity seems to be this touchy subject. Manu Sporny: I got the feeling from Melvin that he was concerned that the identity stuff was a red herring, he felt that the identity stuff wasn't that important Manu Sporny: The community may be split on that, i'm not sure, i'm not sure if the people that are anti-identity understand the entire purchase process Manu Sporny: Eg: you need to transmit identity info to people you buy things from Manu Sporny: Whatever payment system you come up with, if it doesn't cover identity in some way, it will be difficult to use Manu Sporny: Dave Longley, Dave Lehn probably agree, so we need to talk to Melvin a bit more on the mailing list since he's not present on the call Topic: Memorable Payment Identifiers Manu Sporny: Use case #1: A person sends money to their friend using a memorable identifier instead of a complex account number or URL. The memorable identifier is translated to a destination account for the payment. The friend should be able to easily communicate the identifier via voice, SMS or other short message and the person should be able to easily remember it. Manu Sporny: This is a set of requirements more than a use case Timothy Holborn: Identity can assist in supporting use-cases such as digital receipt functionality. say, a retail POS system has a WWW interface, to establish a relationship between the customer and the retailer (inclusive potentially of product / brand relationships). Timothy Holborn: Digital receipt functionality can in-turn extend to loyalty relationships Manu Sporny: +1 Manu Sporny: We can't get away from the identity problem, if we use pseudo-anonymous IDs for all the digital receipts then the receipt has to be tied to the payment provider and we lose all the KYC/AML stuff that's required for high-value transactions. We don't want this to be a toy payment network. Timothy Holborn: A pseudo-anonymous identity effectively diminishes support for the user. warranty related information is one use-case where identity information relating to a transaction (perhaps to a product ID) supports the purchasers interests Timothy Holborn: The choice to provide that information, in a standardised form assists with interoperability Timothy Holborn: Ideally, the user has a service that allows them to store that information and select privacy preferences surrounding the relationship style with any participating retailers. Dave Longley: So, we should reword it so that someone wants to send someone else money, they ask for their "short payment identifier". The payment is sent to that short payment identifier. The payment system translates the short payment identifier into the correct destination account. [scribe assist by Manu Sporny] Timothy Holborn: Understanding that’s a model of implementation, not a specification. Timothy Holborn: Re: short payment identifier +1 Manu Sporny: So, the use case should be: Jack wants to send Jill some money and asks Jill for a short, memorable payment identifier. Jill sends the payment identifier to Jack via an SMS message. Jack makes a payment using the short payment identifier, the payment processor translates the short payment identifier into a destination financial account for Jill. Dave Longley: It's more about identity than payment initiation Timothy Holborn: Could be like a robot.txt file Dave Longley: First the translation of short id to financial account would occur then payment initiation would take place Topic: Trusting Short Payment Identifiers Manu Sporny: Ok, so Evan's next use case is: A person needs to pay a (large) merchant for a purchase. They should be able to easily check that the destination is legitimate and, for example, not the address of a spammer (e.g. payments@amazon.com is preferable to a numerical account number and simply "Amazon" is preferable to a longer identifier because some users may be fooled by something akin to "amazon-payments@banksrus.com"). Manu Sporny: I think this has more to do with verifying an identity is who you think it is Timothy Holborn: +1 Manu Sporny: You would probably never manually type in "amazon" to the payment provider, you would be on the amazon website to click buy Manu Sporny: You wouldn't need to verify the person receiving the payment was amazon Manu Sporny: I think this really has to do with identity discovery Dave Longley: This seems like more of a requirement, this just falls out of having short payment identifiers map to identities. [scribe assist by Manu Sporny] Timothy Holborn: How about simply linking a URI to a payment destination Dave Longley: The way this use case is describing verification has to do w/ the way people are creating identifiers. [scribe assist by Manu Sporny] Timothy Holborn: Linking payment identifiers? Dave Longley: This doesn't have to be a built in feature - short verifiable identifiers don't need to be verifiable, the person using the system would use something that would inspire confidence. This is external to how the system is standardized itself. [scribe assist by Manu Sporny] Dave Longley: I think what Evan was trying to say is that the short identifier should be verifiable, and that's not something you can build into the system. It's a choice that someone would have to make. There is no system of trust around the identifier. You don't know if "Amazon" is actually Amazon unless there is someone verifying the name. [scribe assist by Manu Sporny] Timothy Holborn: Wouldn’t something like WebID-TLS support that sort of function (or X509v3 - subjectAltName URI’s?) Timothy Holborn: Subject to the issuing party i guess... Manu Sporny: Tim, not really, no Dave Longley: Once you map the name to a URL, you can look up that URL and see if you get something like an x509 certificate back, but there is no security inherent in the name itself. [scribe assist by Manu Sporny] Timothy Holborn: Could shorten a URL that relates to a persons profile document - say a facebook profile, or a linkedin profile. however the recipient of the transaction would need to register that address and verify it. Manu Sporny: I think what he means is something akin to the padlock icon in the browser, but associated w/ the short name. Timothy Holborn: So a provider creating short-names for authorised links? Dave Longley: Maybe this is a use case for sending a tweet to do a purchase, etc. Dave Longley: Vs. being on their website Timothy Holborn: So, network = twitter identifier = @payswarm ? Manu Sporny: Ok, so how about this: A person needs to pay a merchant for a purchase using a short identifier. They should be able to easily verify that the funds are going to be transferred to the appropriate merchant by looking at information associated with the short identifier that validates that they are, in fact, the merchant that they thought they were sending the money to. Manu Sporny: Tim, yeah, kinda like a short name for a payment destination... Timothy Holborn: Donations or micropayments - the ‘busker’ use-case… Dave Longley: A person pays a merchant using a short identifier. Prior to sending the payment, some information associated with the short identifier indicates to them that the short identifier is properly associated with the merchant. [scribe assist by Manu Sporny] Dave Longley: A person pays a merchant using a short identifier. Prior to sending the payment, some information associated with the short identifier indicates to them that the short identifier is a verified short identifier for the merchant. [scribe assist by Manu Sporny] Dave Longley: So, this could be some sort of Twitter advertisement for an item to purchase. You could then tweet back at the item to purchase it using the short identifier. [scribe assist by Manu Sporny] Timothy Holborn: …’Verified short-identifier for the intended recipient? Dave Longley: You could hover over the identifier and effectively see an Extended Validation certificate, ensuring that you are sending payment to the proper destination. [scribe assist by Manu Sporny] Dave Longley: This is really about mapping a short identifier to a longer identifier, that's basically it. [scribe assist by Manu Sporny] Timothy Holborn: Or a campaign for planting trees is being driven via twitter for a named value (say, $5) all you need to do is send ‘buy a tree’ to @buyatree on twitter (presuming both accounts are linked, it works?) Dave Longley: Other operations can be done on top of that to get credentials, etc. create fancy UIs Manu Sporny: So, this could really be a standard for URL compression for the Web... standardizing short links. Manu Sporny: Tim, yeah, I think that's the basic use case. Dave Longley: So, something like - DID:ManuSporny Dave Longley: If we do the whole decentralized identity thing, we could just have a new scheme, and they would pick a name using their identity, so the solution would be to just tack the name to the end of that decentralized URL scheme. [scribe assist by Manu Sporny] Dave Longley: (DID = decentralized ID URL scheme) Dave Longley: The short identifier in that case would be "ManuSporny" Timothy Holborn: Decentralised or ontology based? Dave Longley: It would be decentralized Manu Sporny: So, @ManuSporny on Twitter would be translated to did:ManuSporny, which would then hit some sort of decentralized lookup, which would return a URL to where you could get the certificate and destination accounts for the individual. Manu Sporny: Tim, they're not exclusive (decentralized vs. ontology) Dave Longley: It would be both, but in this case we're talking about decentralized Timothy Holborn: I’m just thinking that the use of an ontology might help with an identifier, but only so many english terms… it’s nice to use your own domain... Topic: Short Payment Identifiers for Donations Manu Sporny: Ok, Evan's third use case - A charitable organization or cause posts a donation address on a print advertisement. The address should be as memorable as a social media username so prospective donors need not use QR codes or type full URLs, potentially on a phone, to send a quick donation. Timothy Holborn: Not just english - perhaps another facet Timothy Holborn: We're talking about where your ID wouldn't be linked to a domain Dave Longley: Your ID wouldn't have to be tied/locked down to a particular domain, rather the ID itself would be abstracted from the document storage location Dave Longley: So you could move where your identity document is stored easily without having to change your ID Timothy Holborn: Understand… still thinking it through. Dave Longley: These are all about having an identifier that is short and memorable. The other qualities are that it "looks accurate". [scribe assist by Manu Sporny] Timothy Holborn: @ Is used to denote an email address or a twitter address. Timothy Holborn: # Is also used... Timothy Holborn: Could be something simple like that… perhaps $ Dave Longley: I think we've covered this, you can have a short identifier map to a longer one. However, what the short identifier looks like is up to user choice. We can't enforce that w/ a standard. [scribe assist by Manu Sporny] Dave Longley: We have an idea for a system once you map it to an identity, you can map it... the short ID and how it looks, if it looks spammy, is not enforceable by a standard. Since we're not choosing them for people, they can chose whatever they want, it's an open question to what a short identifier looks like. [scribe assist by Manu Sporny] Dave Longley: We can't lock down the choices people will make on the short identifiers. [scribe assist by Manu Sporny] Dave Longley: Effectively all that is is that there is a credential issuer out there that will issue short IDs to people, and then people can map that back to their short identity. We will probably do the reverse of that, make it easy to have a short identifier to map to your list of credentials, and then check that identity's credentials to ensure that you're sending stuff to the proper location. [scribe assist by Manu Sporny] Timothy Holborn: Does the concept of a payment equivalent to an email address have sufficient merit... Dave Longley: Really, all of this stuff just sounds like the abstraction we've been moving toward wrt. separating identifier to document storage location. If you don't get a URL scheme, you can prepend it, that may be all we're talking about here. [scribe assist by Manu Sporny] Manu Sporny: Tim, I think we're thinking along the lines of just a short name scheme that maps to a URL... Manu Sporny: And there being some way to look up the mapping that's decentralized. Manu Sporny: (And perhaps requiring payment to have that mapping in the "global ledger") Manu Sporny: So, we're skipping the last use case? Timothy Holborn: I can think of a few solutions that could support such functions. i’m not sure specifying one would be helpful atm. Dave Longley: Yeah, the thing that's compelling is that you have a memorable short address to send payments to. [scribe assist by Manu Sporny] Timothy Holborn: Other than the ability to provide one. Dave Longley: Cryptocurrencies use base-64 public keys for IDs, those are not useful to people. They don't have the same memorable features that people would like to have. [scribe assist by Manu Sporny] Dave Longley: Give "ManuSporny" to identity/payment software, it prepends URL scheme - did:ManuSporny, then a decentralized network query returns a result that can be used to get a URL to an identity document Timothy Holborn: ATM, best solution i’ve seen is putting a crypto wallet address into a foaf file Timothy Holborn: I assume the webpayments identity solution has a similar means of notating an identity, with relavent URI's Manu Sporny: Yep, it does Timothy Holborn: Principally, we can’t get away from the identity issue. Manu Sporny: So, this is useful for quick one-off payments, and may come about because of other stuff we're working on right now. Timothy Holborn: The identity solution, supports an array of payment mechanisms. ideally, the debitor can select which transaction format best suits their needs for that transaction Manu Sporny: But payments to short identifiers is probably low priority as it's a convenience mechanism, not absolutely necessary to perform a payment in may common B2C use cases. Timothy Holborn: Perhaps assign different terms to different gateways / payment identifiers Timothy Holborn: QR Code is a useful tool... Dave Longley: Something important wrt. where this identity information lives. For example, in a telehash-like network, if you query a short name, you could get a URL sent back to you. [scribe assist by Manu Sporny] Timothy Holborn: Agreed. low priority atm. Dave Longley: There is also information leakage issue, you don't want to make some of this information public. [scribe assist by Manu Sporny] Timothy Holborn: +1... Dave Longley: Also, Telehash was supposed to be temporary, but now we're talking about having that network persist. The software wouldn't have any idea of how to map it to anything w/o that network. [scribe assist by Manu Sporny] Timothy Holborn: http://telehash.org/ Manu Sporny: Well, the question is, is that mapping mechanism a nice-to-have or is it a must have. Dave Longley: If we're going to have a shortname lookup mechanism, it would have to be standardized, it would be a must have, and that may be biting off more than we can chew. [scribe assist by Manu Sporny] Brent Shambaugh: Mozilla also is doing something new Brent Shambaugh: What's Mozilla doing? [scribe assist by Manu Sporny] Topic: Loyalty Cards, Tokenization Manu Sporny: Ok, let's see if we can drop these two use cases, I think we've already got them covered. Timothy Holborn: Link? Manu Sporny: https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Initiating_Payments Manu Sporny: I think we can drop these two: Manu Sporny: Application of loyalty cards to purchases. Manu Sporny: Tokenization mechanism that protects the buyer and merchant from theft of credentials. "Use Case: A customer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits." covers the above loyalty card case Timothy Holborn: Why loyalty card. do you have loyalty relationship? perhaps form loyalty relationship? Manu Sporny: It's about a loyalty relationship (not the card itself) Manu Sporny: But we already have the use case that Dave pointed out above, so it's a duplicate. Timothy Holborn: Ok. few ideas, see if you’ve got them covered. Manu Sporny: "Use Case: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account." Manu Sporny: "Use Case: Tokenization mechanism that protects the buyer and merchant from theft of credentials." Manu Sporny: So, those are duplicates, condense into one? Brent Shambaugh: Manu, Mozilla has a new project called Accounts that sounds kinda like what you guys have been talking about. Timothy Holborn: I have NFC tag that links to my RWW Dataspace. i buy with cash, tap NFC, then later set my relationship privacy settings with merchant, participate with how many bottles of ice coffee i buy in a month (any outlet). Timothy Holborn: Get my reciept sent via HTTP Brent Shambaugh: One is the token, and one is the mechanism Manu Sporny: https://blog.mozilla.org/blog/2014/02/07/introducing-mozilla-firefox-accounts/ Manu Sporny: Brent, aren't Firefox Accounts specific to the Firefox web browser? Manu Sporny: They're not cross-browser compatible, right? Timothy Holborn: I can log into chrome Manu Sporny: Yes, but that's not powered by Firefox Accounts - it's like it, but totally different system. Timothy Holborn: Understand… same sort of thing though, isn’t it? Manu Sporny: It's not a generalized solution, it's browser-specific, but yes, same sort of thing. Timothy Holborn: I believe with alot of existing POS systems, it’s easiest to hijack the print-driver Manu Sporny: RWW Dataspaces, Identity Credentials are better (because they're completely cross-browser) Brent Shambaugh: It sounded like that when it was described to me (from a person from Mozilla). Brent Shambaugh: That it was a generalized solution? [scribe assist by Manu Sporny] Brent Shambaugh: No, I think he described it as browser-specific. Timothy Holborn: The current loyalty use-case seems to be overly specific Timothy Holborn: Perhaps linkage of loyalty (or receipt) information to purchases? Brent Shambaugh: I might be able to get ahold of him if you want. Timothy Holborn: Or transactions? Timothy Holborn: Therein, perhaps the mechanism around support it is where tokenization lives. Timothy Holborn: But it’s not simply from theft of credientials Timothy Holborn: Also; is loyalty also a constituant of digtital reciept Brent Shambaugh: Do you remember who you were talking w/ at Mozilla? [scribe assist by Manu Sporny] Brent Shambaugh: In any case, it's probably important to track the work, but it won't be useful for what we're doing unless it could be standardized (and Mozilla doesn't seem to be very interested in that right now) [scribe assist by Manu Sporny] Timothy Holborn: "Use Case: A customer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits." <-- that one is overly specific? Dave Longley: That's what we replaced the use case that mentions loyalty cards with, is that ok with you? Timothy Holborn: +1
Received on Wednesday, 28 May 2014 17:12:51 UTC