- From: <msporny@digitalbazaar.com>
- Date: Wed, 25 Jun 2014 12:03:18 -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-06-24/ 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-24 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0170.html Topics: 1. Introduction to Timothy Ng from Microsoft 2. Internet Governance Forum 2014 3. RequestAutocomplete Use Case 4. Transmission Format of Credentials 5. Data Accountability Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Timothy Ng, Pindar Wong, Timothy Holborn Audio: https://web-payments.org/minutes/2014-06-24/audio.ogg Dave Longley is scribing. Manu Sporny: Anything else to add to the agenda? David I. Lehn: Nope Topic: Introduction to Timothy Ng from Microsoft Timothy Ng: My name is Tim, I work at microsoft, I am an architect on the commerce platform service at MS, we're responsible for building out all of the online and some of the offline physical store payment stuff, we serve all the MS properties today, if you go to an MS store, use xbox live, online business and sign an agreement with us, it goes through our platform, we are looking at third parties build on top of our platform in the future but we haven't put too much thought into that Pindar Wong: Nice to meet you Tim. Timothy Ng: I'm responsible for stuff/architecture on the payments side. Pindar Wong: I'm a consultant/early stage investor, introduced to this work via creative commons, I'm trying to drive/promote Web Payments in the Asia/Pacific region. I'm based in Hong Kong, I advise on infrastructure. I helped pioneer the Internet/Web infrastructure here 20 years ago, worked with primarily telecoms and ISPs, I try to promote all this work, etc. Timothy Ng: I'm from Hong Kong we should meet up while I'm over there. Manu Sporny: It would be great for you guys to meet at some point, pindar only covered 2 percent of what he does. He's been instrumental in moving the Web Payments stuff forward. Dave Longley: Hi, I'm Dave, I'm the CTO at Digital Bazaar - worked on JSON-LD, put a lot of design work and implementations into PaySwarm, spend most of my time implementing software, architecture, payments. [scribe assist by Manu Sporny] Timothy Holborn: I’m a media techologist. Working on ‘semantic web’ systems, more focused on media distribution since about 2000. I was involved with Hybrid TV systems (VOD, etc. ISP datacentres, etc. prior to that) a body of work that built into https://www.hbbtv.org/ (project kangaroo, Freeview, which later formed Hbb) having identified http://tools.ietf.org/html/rfc4078, getting in touch with stakeholders in 2007 after delivering the first VOD (RTSP) over DSL2 system in OZ. After that work, i became involved in the rollout of Digital Cinema Infrastructure (DCI Approved) in Australia / NZ. In 2010, I restarting the ‘knowledge banking’ platform project, believing the technology standards (RDF/semantic web) were reaching a level where it was possible to deliver something that isn’t propriatery system with undue lock-ins … I’ve been working on W3 related standards, as to ensure no-golden handcuffs on the underlying data-services platform (dataspaces) since about 2000. Web-Payments capabilities are a counterpart of that work. David I. Lehn: I'm Digital Bazaar's Director of Research and Testing and spend most of my time implementing and testing the Web Payments technologies we discuss on these calls and others. I've written implementations for JSON-LD, HTTP Signatures, Web Commerce, Web Payments, Secure Messaging, Identity Credentials, and many of the other specifications we're doing active work on here. Manu Sporny: Welcome to the group, Tim. :) Topic: Internet Governance Forum 2014 Manu Sporny: I think we're good as far as the agenda for the IGF is concerned Manu Sporny: We updated the workshop proposal for the IGF that is in turkey in a couple of months, we are getting more positive responses on attendance. Here's the updated proposal: Manu Sporny: http://www.intgovforum.org/cms/wks2014/index.php/proposal/view_public/69 Manu Sporny: The MAG at the IGF asked us to make a couple of clarifications on our proposal, i believe we made all of them submitted and live now Pindar Wong: Thanks for the update and dealing with this Manu, sorry for the hassles. Manu Sporny: The additions were: we put down a rough agenda that you can see at the top of the link, intro to web identity, etc. ... then we asked some fairly straightforward policy questions, hopefully that will trigger the group work, ... for before we had the british computer society, Electronic Frontier Foundation, w3c will most likely join us on the panel, bloomberg has said they want to participate via video, but may not be able to send someone for just one workshop, but may do a video, US fed is trying to send someone, world bank is definitely interested and trying to find someone, mozilla is MIA, ripple might send someone, i think we're good, pindar, what's the next step? Pindar Wong: We don't need to do anything, just make sure everyone does their videos, things will be fairly loose up until the event itself, i'm expecting that they'll confirm and get publically listed Pindar Wong: The main thing to note is that we're trying to change the format so that we can have as much product use of time in Istanbul Manu Sporny: Thanks pindar, we'll start pushing attendees to submit videos next month. Topic: RequestAutocomplete Use Case Manu Sporny: We have this right now: Reject the form auto-fill anti-pattern (RequestAutoComplete) and move to one that doesn't result in security risks if data is stolen at the merchant. Manu Sporny: The way the RequestAutocomplete use case was described at the workshop was not a use case, it was a rejection of RequestAutocomplete or its general strategy Manu Sporny: One of the arguments against it was that it transmits secrets that we wouldn't be transmitted using a new payment mechanism Manu Sporny: Sending CC to a merchant seems like a very bad security practice, the question is ... do we want to standardize bad security practices like that? Manu Sporny: Previously we did discuss, in other use cases and requirements during the workshop, we want to use tokenization and we don't want to unnecessarily transmit secrets to vendors, etc. Manu Sporny: How do we reorder it so that don't reject RequestAutocomplete outright, but rather discuss it and say what we don't wnat Manu Sporny: We want these mechanisms to be secret free, if a thief steals a token we want it to do little to no damage Pindar Wong: I'm in favor of keeping it clean Pindar Wong: I do view it as a bridging mechanism and outside of the scope of our work Dave Longley: I agree with Pindar, it seems like it's a bridging mechanism. This is really about filling out information automatically for people using the existing system in place. [scribe assist by Manu Sporny] Dave Longley: We're talking about redesigning that piece to ensure that secrets are not necessary, vendors only get what's required for payment. Information needs to be stored in a way that is automatically completed for people, but not via form auto-complete. With Identity Credentials, you can store low or high stakes credentials, and you provide that information on a need to know basis. [scribe assist by Manu Sporny] Dave Longley: The information will be filled in on a need to know basis. So, I don't know exactly want to say about this use case. [scribe assist by Manu Sporny] Dave Longley: We don't want to do what the RequestAutocomplete feature does, but we do want to provide an equivalent functionality. [scribe assist by Manu Sporny] Manu Sporny: We probably should not say RequestAutocomplete at all because we don't need to talk about specific technologies here at all Manu Sporny: When we go one level up, we want to enable certain pieces of transaction information to be autofilled and we don't want to transmit secrets, and if any information is stolen we don't want the thief to get any sort of large advantage Manu Sporny: I believe we have these features covered Pindar Wong: Assuming breach at some point is worth reiterating Pindar Wong: One of the problems of this phrasing is a failure of imagination, once people see the other tech what we write here will make much more sense Manu Sporny: We don't mention it specifically, we don't say "assume security breaches" we do say that any information stolen is useless to the thief Manu Sporny: Should we be more specific and assume security breaches? Dave Longley: Yes, this is a design criteria - assume security breaches. [scribe assist by Manu Sporny] Manu Sporny: It sounds like a design criteria Pindar Wong: That's my personal preference Manu Sporny: PCI folks may take issue with that assumption, but the status quo isn't great either. Cost of a security breach currently for a merchant that accepts credit cards is fairly high. Manu Sporny: So we have this: Use Case: Transmit one or more pieces of information before a purchase occurs such that the identification of participants in a transaction can be performed. Dave Longley: Let's not focus on auto-filling - you can transmit your shipping information w/o having to fill it out at every vendor you go to. [scribe assist by Manu Sporny] Topic: Transmission Format of Credentials Timothy Ng: I have a quick question, one of the implications of RequestAutocomplete, is that there's a standard representation of that piece of information, for example, on certain implementations, on safari, if the expiry date is a combo box, it doesn't quite work, if it's a plain text box it works, same with addresses, depending on the address structure on the website it doesn't always work properly, it misses the zipcode if it's not labeled property, in order for autocomplete to work there has to be a standard piece of information for your credit card or your country, if we represent it differently than a browser can't easily auto fill it in without having to make guesses Timothy Ng: I wonder if what's interesting is what the thing is to be sent, like a CC, it's just a feature of the browser then it becomes easy Manu Sporny: The assumption that we're making is that JSON-LD is used pretty heavily throughout many of the specs that we're talking about Manu Sporny: Google, MS, Yandex, and Yahoo now have a standard address format that seems to work worldwide (schema.org) Manu Sporny: We were going to build off of that work Manu Sporny: You're absolutely right is that we need a standard way to transmit the information, rather it's in a JSON message Manu Sporny: If a vendor needs a proof of age from your and a shipping address and they'd get two JSON objects that would be in a world-wide standard form Manu Sporny: I don't think it addresses everything, i'm not trying to paper over the way certain addresses are made in one country vs. another, but the assumption we're talking about is that at some point we'd come up with a standard for representing each one of these pieces of information Dave Longley: It's important that we keep the abstraction clean there. We don't want to have to match up UI forms w/ how the information was entered. At the end of the day, we don't want people markup forms for getting shipping information. [scribe assist by Manu Sporny] Dave Longley: You don't even have to think about what the UI looks like. Because the standard is not there, we fall back to the UI. [scribe assist by Manu Sporny] Timothy Holborn: Isn’t most of the traditional autocomplete information contained within the identity credientials declaration? Manu Sporny: Yes, tim it is Manu Sporny: Simple stuff like proof of age, address, simple stuff like that is there, yes Manu Sporny: The assumption we're making here are that those pieces of information are a different part of the system Manu Sporny: Address, name, proof of age, etc. aren't that difficult Dave Longley: By using JSON-LD, we've essentially decoupled the need to standardize the protocol for transmitting this information from what the information looks like. [scribe assist by Manu Sporny] Dave Longley: We can say that there is an ontology that describes what the information looks like, which is different from what the JSON-LD message looks like. [scribe assist by Manu Sporny] Timothy Holborn: Their’s two tiers? the merchant and the identity provider… i’d imagine, most of the traditional ‘claims’ were entered directly via the mechant UI Timothy Holborn: The identity structure has [missed], traditionally you've been giving the information to the merchant, with the autocomplete, facebook connect, etc. it pulls that from some source browser, whatever, i would think with identity credentials, the constituents [missed] Manu Sporny: I think that's true, there will be enough people pushing on this stuff to figure out what the format for these messages will look like pretty quickly Timothy Holborn: For a driver's license, the address will be attached to that, right? Manu Sporny: It's definitely paired with the IC and in the information that is sent over. Manu Sporny: It may not be us that standardizes the format, or may be ... but other groups/orgs can get together and standardize it w/o our consent which is exactly what we want. Each market vertical is going to want their own type of info. Dave Longley: Because that work has been done, and because people are publishing schema.org addresses, we'll probably just re-use that. The problem is being solved as we speak. [scribe assist by Manu Sporny] Manu Sporny: We've already gone through a lot of the churn over the past 10 years to create ontologies for this stuff, we should re-use them. Timothy Holborn: I agree Timothy Holborn: We've got an identity provider that has that sort of information and we've got a merchant, most of the autocomplete form data would come from the identity provider itself. Dave Longley: Yes, that's how it'd work. Identity Credentials spec holds all identity data at identity provider, it comes from there. [scribe assist by Manu Sporny] Dave Longley: We currently have this: Transmit one or more pieces of information before a purchase occurs such that the identification of participants in a transaction can be performed. Dave Longley: We could alter that use case a bit. [scribe assist by Manu Sporny] Timothy Holborn: Provide pre-approval of a participant using identity credentials? Dave Longley: Maybe something like this - Transmit one or more pieces of information (such as proof-of-age, shipping address, etc.) to a website to enable access or fulfillment of a transaction. Manu Sporny: +1, May want to mention authorization and access/fulfillment. Dave Longley: Ok, so this? A customer visits a website and authorizes the transmission of one or more pieces of information (such as proof-of-age, shipping address, etc.) previously stored with an identity provider to the website to enable access or fulfillment of a transaction. Timothy Holborn: +1 Manu Sporny: +1, I'll commit that to the use case list. Topic: Data Accountability Manu Sporny: The last part of the RequestAutocomplete one is covered by this use case: Use Case: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Tokenization mechanism that protects the buyer and merchant from theft of credentials. Dave Longley: Do we want to say something about a Design Criteria - avoid trying to guess how browser should complete web forms. Do we want to say something about sharing secrets design pattern. [scribe assist by Manu Sporny] Manu Sporny: Is this what we want? Design Criteria: Avoid solutions that require customer secrets to be unnecessarily exposed to merchants. Dave Longley: Particularly, secrets that could cause great damage if stolen. Group discussion around attaching some sort of accountability to the data transmitted, whether or not that is in scope, whether or not it's technically achievable, and whether or not it's politically achievable. Timothy Holborn: What about attaching accountability to data that's transmitted? [scribe assist by Manu Sporny] Manu Sporny: Well, we don't want to transmit secrets at all if possible. Credit card numbers, definitely not. Address information, is a secret that could cause damage. Dave Longley: We don't want to try and standardize that because we don't know how to protect address information very well. [scribe assist by Manu Sporny] Timothy Holborn: It’s outside of scope, to protect information that has been passed to the merchant (address information, etc.). Dave Longley: I think we have enough information in the use cases where we can just strike the "reject RequestAutocomplete" one. We don't really even need the design criteria. [scribe assist by Manu Sporny] Manu Sporny: Ok Timothy Holborn: The ability to log requests to/from the identity provider is an option - however this may be a value-add. in theory, a few levels exist; no logging, selective logging, mandatory logging. this doesn’t protect data that has be previously sent to the mechant - even if a unique key has been generated for each information sharing event. Manu Sporny: I agree about the philosophical goal, don't know if we can prescribe that. Dave Longley: What are the elements that are interoperating here? We don't want to be overly prescriptive. [scribe assist by Manu Sporny] Timothy Holborn: If something doesn't conform wrt. W3C Validator, it doesn't conform. It takes a position. I'm wondering if this is one of those cases. Users have traditionally not had the same level of accountability as companies. There are implications to that in practice. [scribe assist by Manu Sporny] Timothy Holborn: Maybe we should say that protocol should state clearly that it's logging something, logging everything, etc. [scribe assist by Manu Sporny] Dave Longley: The point would be to build a tool that would ask "What is your level of logging?". People don't want to automate where they're putting their identity information so they're not auditing it on a personal level. [scribe assist by Manu Sporny] Timothy Holborn: I think it's the identity provider that would have the logging capability. I think there would be options provided by a compatible service. It could simply be in the receipt. [scribe assist by Manu Sporny] Dave Longley: So a merchant would be able to ask the identity provider if they're logging the information. [scribe assist by Manu Sporny] Timothy Holborn: Let's say service gives you a digital stamp that's traceable. Where that log might live might be w/ the identity provider. [scribe assist by Manu Sporny] Timothy Holborn: A "law-to" relationship - you go to a local shop, they have windows running their POS system, you tap your phone and get your digital receipt, you can specify your loyalty relationship w/ the merchant. How much is that merchant interrogating your data? What are your privacy preferences. [scribe assist by Manu Sporny] Timothy Holborn: If the data exists and you can pull it up, it empowers people to use the data that exists and provide accountability. [scribe assist by Manu Sporny] Manu Sporny: So, you're basically saying that you want people to be empowered by knowing when people are reading their personal information. [scribe assist by Manu Sporny] Timothy Holborn: Just saying that having that data available can be important, identifying what data is being made available is as important as not getting it. [scribe assist by Manu Sporny] Dave Longley: An additional spec that could come out of this work could be an optional API for identity providers that would allow you to gather data on who's been requesting your information. [scribe assist by Manu Sporny] Dave Longley: At the same time, you still don't know if they're logging that information. They could only store 10 things - even if that standard exists, it's still policy/trust that people have when they personally audit a place where they store the identity - it's outside of the technology. [scribe assist by Manu Sporny] Manu Sporny: Ok, we're out of time this week, see everyone next week.
Received on Wednesday, 25 June 2014 16:03:42 UTC