W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

Web Payments Telecon Minutes for 2014-06-24

From: <msporny@digitalbazaar.com>
Date: Wed, 25 Jun 2014 12:03:18 -0400
Message-Id: <1403712198966.0.11550@zoe>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC