Web Payments Telecon Minutes for 2014-08-06

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-08-06/

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-08-06

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Aug/0030.html
Topics:
  1. Formation of Credentials Community Group
  2. Identity Use Cases Revisions
  3. Credential Transmission
  4. Digitally Verifiable Credentials (KYC)
  5. IdP Mechanism
  6. Truly Anonymous Transactions
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, David I. Lehn, Evgeny Vinogradov
Audio:
  https://web-payments.org/minutes/2014-08-06/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Last week we covered general comments, not a lot of 
  response to it, so we may be good as far as that's concerned
Manu Sporny:  We need to add the credential CG launch to the 
  agenda, we're going to try to do that today, get all the 
  paperwork for that worked out and get that launched today
Manu Sporny:  Any changes to the agenda?
David I. Lehn:  None

Topic: Formation of Credentials Community Group

Manu Sporny: The charter for the group is here: 
  https://docs.google.com/document/d/1dPzWbPF0jlox8UHnr522nBWCjLJMQ_vGbbtsA5-pAsg/edit
Manu Sporny:  We have had feedback from orgs that aren't part of 
  web payments but are part of the education community, the charter 
  has been approved by other orgs that plan on joining, the order 
  of operations will be to create the CG today after making some 
  last few modifications to the charter, we'll send out a call for 
  participation, then we're going to be asking for launch partners 
  through the rest of the month, we're going to gather all the 
  large companies that want to be part of the announcement of the 
  group to the press; the group is for the standardization of 
  credentials for use in payments, education/learning, and 
  background checks.
Manu Sporny: Aug 7th-9th: W3C Credentials CG is created at W3C 
  (paperwork complete)
Manu Sporny: Aug 10th-30th: Revise charter, determine telecon 
  times, have at least 1 call, gather "launch partners" for formal 
  public announcement at the end of August, vote on charter
Manu Sporny: Aug 19th: Presentation of Credentials CG initiative 
  at SemTech 2014, ask of audience is: join the work, meet at 
  Credentials CG
Manu Sporny: https://web-payments.org/slides/2014/semtech/
Manu Sporny: 
  http://semtechbizsj2014.semanticweb.com/sessionPop.cfm?confid=82&proposalid=6674
Manu Sporny: Sep 2-5th: United Nations - Internet Governance 
  Forum - The Payment, Privacy, Policing Paradox Workshop
Manu Sporny: 
  http://igf2014.sched.org/event/781846f97d253b11129ee88f4dd176ff
Manu Sporny: Gather regulatory, policy, and legal concerns, 
  recruit the necessary governments and law makers to provide input 
  on the privacy / law issues
Manu Sporny: Sept 15-Oct 25th: Weekly Credentials CG telecons, 
  picking WG chairs, discuss use cases and requirements, determine 
  when technical specs will be ready to go standards-track at W3C
Manu Sporny: Oct 27th-31st: W3C Technical Plenary - 1st Web 
  Payments Face-to-Face (credentials are an element), 1st 
  Credentials CG Face-to-Face (unconference session)
Manu Sporny: http://www.w3.org/2014/11/TPAC/
Manu Sporny:  Any questions on the credentials schedule?
No questions raised.

Topic: Identity Use Cases Revisions

Manu Sporny: Identity use cases: 
  https://www.w3.org/community/webpayments/wiki/UseCases#Identity
Manu Sporny: So, we're starting with this use case: Store basic 
  credentials and payment provider information on the Web in a way 
  that is easy to share with various payees/merchants given 
  authorization by the owner (payee) of the credential, and that is 
  easy to synchronize between devices.
Manu Sporny: Input from Steven Rowat: I think we need to have 
  more discussion about identity's implications before deciding 
  whether to attempt to do it together with web payments.
Manu Sporny: Input from Adrian: Not required for first iteration. 
  It is not ESSENTIAL for the payer to exchange identity 
  credentials to complete a basic transaction. Think this should be 
  the focus of 2nd iteration.
Manu Sporny:  With the credential CG happening, i think what 
  we're doing is offloading all of this identity discussion to that 
  CG, if there's concern in the web payments CG for identity 
  derailing us, the credential CG will pick up the use cases
Dave Longley:  I think what's most important in the web payments 
  work is that there is some way to link to an identity via a URL. 
  We should consider whether the Credential CG, having that link 
  should be enough for what we want to do w/ Web Payments. If all 
  we need to do in Web Payments is ensure that the URL is 
  available, then all the details can be worked out by the 
  Credentials CG. [scribe assist by Manu Sporny]
Dave Longley:  The goal is to decouple as much as possible, but 
  still cover all the use cases we wanted to. We can consider this 
  a first iteration where we want to concern ourselves with those 
  pieces. [scribe assist by Manu Sporny]
Manu Sporny:  If we take this path and if for whatever reason the 
  credentials CG fails, we could use OpenID connect to establish 
  the URL, but we wouldn't get anonymity, privacy, etc. and of 
  those things
Manu Sporny:  But at least we could do something
Manu Sporny:  So i think that addresses steven and adrian's 
  comments, re: steven, it's the other group's decision to figure 
  things out, and re: adrian, we aren't handling the identity stuff 
  for iteration one

Topic: Credential Transmission

Manu Sporny: Ok, on to the next use case - Use Case: Steve 
  (buyer) visits a website (merchant) and authorizes the 
  transmission of one or more credentials (such as proof-of-age, 
  shipping address, etc.) previously stored with a credential 
  storage service to the website to enable access or fulfillment of 
  a transaction.
Manu Sporny: Feedback from Adrian: Not required for first 
  iteration. It is not ESSENTIAL for the payer to exchange identity 
  credentials to complete a basic transaction. Think this should be 
  the focus of 2nd iteration.
Manu Sporny: So, resolution for both is: A Credentials CG is 
  being created to handle all identity requirements for Web 
  Payments (and other market verticals). The Web Payments CG will 
  proceed assuming that there will be a mechanism to establish an 
  identity URL for participants in a transaction.
Manu Sporny: Next use case is: Using metadata that is the result 
  of a transaction, discover attributes associated with the 
  participants (payer, payee, buyer, merchant) in the transaction.
Manu Sporny: Response from Steven Rowat: wouldn't someone in the 
  NSA be doing exactly this? Or Google, to get data to drive 
  advertising revenue? Isn't there a good case that this is 
  unconstitutional in the US?   I don't think this is what you 
  mean...but what do you mean? Who needs to discover attributes 
  associated with the identity of the participants? Why not just 
  ask the participants? 
Manu Sporny:  Steven's questions all surround who has the rights 
  to the data
Manu Sporny:  His concerns would be that someone could get meta 
  data from the receipt, but that's not what we want it's up to the 
  owner of the identity to release the data
Dave Longley:  There was a lot of misunderstanding over this use 
  case. This isn't meant to wipe out all other use cases about 
  privacy. This was about the participants being able to access 
  other participants data WITH THE STRICT APPROVAL of the 
  requestee. [scribe assist by Manu Sporny]
Dave Longley:  If you want to provide the information, there is a 
  mechanism to do so. We should reword it. "Should the participants 
  agree..." [scribe assist by Manu Sporny]
Dave Longley:  I think that resolves all of Steven's questions. 
  [scribe assist by Manu Sporny]
Dave Longley:  What about: Given permission from participants in 
  a transaction, metadata can be obtained to discover attributes 
  associated with those participants (payer, payee, buyer, 
  merchant).
Dave Longley:  We may want to talk about real-time authorization 
  and interactive authorization. Preauthorization via some sort of 
  digital signature, or interactive authorization. [scribe assist 
  by Manu Sporny]
Manu Sporny: Given permission from participants (payer, payee, 
  buyer, merchant) in a transaction, use transaction metadata to 
  discover additional attributes (name, address, preferred 
  financial account) associated with the participants in the 
  transaction in real-time or via an interactive mechanism.
Manu Sporny:  The gist of the use case is that "you have just 
  completed a transaction with these people and you may want to 
  find out more information about them post-transaction"
Dave Longley:  Given the permission of the participants of a 
  transaction, its metadata can be used to discover additional 
  attributes associated with those participants.
Evgeny Vinogradov:  After a transaction has been completed you 
  can't be sure that the information you obtained will be exactly 
  the same afterwards as it was at the time of the txn
Manu Sporny:  That's true. It's a problem wrt. fraud, but it may 
  also be a benefit (getting the most recent, up to date email 
  address or shipping address for a customer).
Dave Longley:  This sounds like you need data in the receipt and 
  have that information only accessible to people involved in the 
  transaction. [scribe assist by Manu Sporny]
Dave Longley:  This is private information that's a part of the 
  receipt. [scribe assist by Manu Sporny]
Dave Longley:  We are talking about having metadata in the 
  receipt itself, in the transaction metadata somewhere. [scribe 
  assist by Manu Sporny]
Dave Longley:  We need to make sure that these receipts are 
  private pieces of information, only accessible by private 
  participants in the transaction. Some of the information is only 
  available to some of the participants in the transaction. [scribe 
  assist by Manu Sporny]
Dave Longley:  This use case is really about two things - you can 
  store metadata that is directly related to the transaction in the 
  digital receipt, and you can indicate who is allowed (of the 
  participants in the transaction), who can see what pieces of 
  information. [scribe assist by Manu Sporny]
Dave Longley:  I think the original design was to leave as much 
  as possible out of digital receipt as possible. [scribe assist by 
  Manu Sporny]
Dave Longley:  In one case, the information is in the digital 
  receipt, in other cases, it's not. [scribe assist by Manu Sporny]
Manu Sporny:  It's the latter, there are pointers, the 
  information lives elsewhere. [scribe assist by Manu Sporny]
Manu Sporny: Given the permission of the participants (payer, 
  payee, buyer, merchant) of a transaction, the transaction 
  metadata can be used to discover additional attributes associated 
  with those participants. For example, given the buyer's 
  authorization, a merchant could query the identity URL for the 
  buyer contained in a digital receipt and obtain an up-to-date 
  shipping address.
Dave Longley:  Another example could be a merchant querying the 
  identity for an up-to-date email address. Keep in mind that this 
  can always be done before the fact, as a part of the login 
  process to the website. The login process would ask for an email 
  credential, shipping address credential, etc. [scribe assist by 
  Manu Sporny]
Evgeny Vinogradov:  Allowing a change to the shipping address 
  after the transaction was made could affect fraud or sales tax, 
  etc
Dave Longley:  Yes, this is an issue. We should make this clear - 
  obtaining information after the fact might have regulatory and 
  fraud implications. [scribe assist by Manu Sporny]

Topic: Digitally Verifiable Credentials (KYC)

Dave Longley:  The next use case: "Use Case: Digitally verifiable 
  credentials such that a merchant and payment processor involved 
  in a transaction can prove that they have performed the proper 
  due diligence when identifying the payer and the payee (KYC)."
Dave Longley:  This, again, falls under the previous resolution
Dave Longley:  For pushing this off to the credentials CG
Manu Sporny:  Once we go over these use cases we'll send them 
  over to the credentials CG

Topic: IdP Mechanism

Manu Sporny: So, this one is next - Use Case: Use an existing, 
  widely deployed identity provider mechanism (i.e. OpenID Connect) 
  to integrate with the digital credentials sharing and payments 
  initiation process.
Manu Sporny: Input from Steven Rowat: would the 'existing, widely 
  deployed' mechanism be part of the specification and go through 
  the same W3C process, and end up being a supported (necessary? 
  sufficient?) part of the whole mechanism? Or is it implied that 
  the i.d. provider mechanism would remain outside the W3C process, 
  which would nonetheless be designed as a socket for it? Or would 
  the payment mechanism have a socket that could fit any number of 
  identity provider mechanisms, without prejudice, but this one is 
  being specified so that there will at least be one example that 
  works for sure? If so, are there downsides to this? For instance, 
  are there other provider or potential provider mechanisms whose 
  developers will be annoyed by being passed over? Or, are there 
  yet-to-be imagined mechanisms that might be better than the 
  chosen existing one, potential mechanisms which will now fail to 
  be developed because one has been already blessed by (association 
  with) the W3C? 
Manu Sporny:  Re: part of w3c, openID connect has already gone 
  through some other standardization process, so no need to discuss 
  that, if we go with identity credentials, that will have to be a 
  part of the Credentials CG work.
Manu Sporny:  Re: would IDP be outside w3c? if it's identity 
  credentials it's inside w3c, if it's openID connect it's outside
Manu Sporny:  Re: specifying the tech ... yes, we have to specify 
  the tech in a way that IDP mechanisms can be pluggable, if they 
  fail, we need a way to have a mechanism establish a URL so that 
  the rest of the stuff can stick together. The payment stuff 
  depends on there being a URL.
Manu Sporny:  Whether it's openID connect, IC stuff, or something 
  else, it's up in the air
Manu Sporny:  Re: downsides? yes, depending on which way we go
Manu Sporny:  If IC is selected, openID connect people could be 
  fairly pissed off about it, if openID connect is selected then IC 
  will be annoyed as it doesn't have third-party digital 
  signatures, JSON-LD, etc.
Manu Sporny:  We are saying that IC spec is going to support 
  openID connect in some way
Manu Sporny:  So we get best of both
Manu Sporny:  Re: can we imagine something better ... we don't 
  know how successful any of this will be, it's an open question, 
  if both fail there will be a better mechanism eventually, we want 
  to make the payments stuff fairly agnostic for how you establish 
  and query the identity URL
Manu Sporny:  That said, i don't think that there are any changes 
  to the use case
Manu Sporny:  These are just clarifying questions
Dave Longley:  We could try to decouple and abstract identity 
  away as much as possible. So, one could use whatever solution 
  that wins in the identity space. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so, Decouple and abstract identity away as much 
  as possible. So, one could use whatever solution that wins in the 
  identity space. No change required for the use case, 
  clarifications have been made on the mailing list and telecon.

Topic: Truly Anonymous Transactions

Manu Sporny: Next use case: Enable anonymous transactions such 
  that the identity of the payee is not discoverable by payees, 
  merchants, or payment processors.
Manu Sporny: Input from Steven Rowat: Do you mean 'but can be 
  discoverable by governments or law enforcement when they have 
  appropriate authorization'?  If so, +1, but I think it would be 
  best to include that explicitly. 
Dave Longley:  I don't see how that could be done, where payees, 
  merchants, and payment processors can't know who you are... but 
  governments can? [scribe assist by Manu Sporny]
Manu Sporny:  The government could assign an identity token where 
  they can only tie it back to the citizen. [scribe assist by Manu 
  Sporny]
Dave Longley:  I meant, I don't see how this could be feasibly 
  done. [scribe assist by Manu Sporny]
Evgeny Vinogradov:  We have to keep in mind governments usually 
  make the payment service providers responsible for ensuring that 
  the identity can be linked back to a citizen, gov't doesn't do 
  KYC clearing by themselves
Manu Sporny:  Yes, good point Evgeny.
Dave Longley:  If you want to use some sort of cryptocurrency 
  that supports this, you should use that. This doesn't have to be 
  a part of the standardization process. [scribe assist by Manu 
  Sporny]
Manu Sporny:  The purpose is to have a cash equivalent
Dave Longley:  I don't think the technologies are worked out for 
  truly anonymous transactions. For example, bitcoin is traceable, 
  zerocash is better, but still being researched. [scribe assist by 
  Manu Sporny]
Manu Sporny: Ok, so position on this is: We do not believe that 
  this is a version 1 feature because the technology to achieve it 
  is still being actively researched and developed.
Dave Longley:  Bitcoin is far more anonymous than other 
  mechanisms, but it doesn't fully achieve the fully anonymous 
  goal. [scribe assist by Manu Sporny]

Received on Wednesday, 6 August 2014 15:26:39 UTC