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

Web Payments Telecon Minutes for 2014-04-30

From: <msporny@digitalbazaar.com>
Date: Wed, 30 Apr 2014 12:53:44 -0400
Message-Id: <1398876824726.0.16031@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-04-30/

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-04-30

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0195.html
Topics:
  1. Graph Signatures Vocabulary
  2. Tim Holborn Request for User Stories
  3. Organizing Web Payments Workshop Use Cases
Resolutions:
  1. Accept the following use case: Store basic identity 
    credentials and payment provider information on the Web in a way 
    that is easy to share with various merchants given authorization 
    by the owner of the identity, and that is easy to synchronize 
    between devices.
  2. Fold the second identity use case ("Managed access to 
    personal identity/attributes as economically valuable assets in a 
    payment system") into the first one, since it consists of largely 
    duplicated information. Do not attempt to address "sale of 
    personal information" in the first iteration of the technology, 
    but keep it in mind while designing the core architecture.
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, David I. Lehn, Melvin Carvalho, Brent 
  Shambaugh, Timothy Holborn
Audio:
  https://web-payments.org/minutes/2014-04-30/audio.ogg

Dave Longley is scribing.
Manu Sporny:  We had a request to add something to the agenda; 
  Tim Holborn wanted to add something about gathering user stories, 
  but unfortunately, it's the middle of the night where he is, but 
  maybe we could talk about his request at a very high level before 
  we talk about the use cases.

Topic: Graph Signatures Vocabulary

Manu Sporny: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0109.html
Manu Sporny:  Melvin raised a question on the mailing list a 
  while ago.
Manu Sporny:  He needs to be able to digitally-sign some 
  information in a different way, specifically, he wants to use an 
  ECDSA-256 curve key to digitally sign JSON-LD information, and he 
  thought he could just use the GraphSignature2012, but the spec 
  for that assumes that you're using RSA and he wants to use 
  different parameters for the signature
Manu Sporny:  The nice thing about the spec is that it lets you 
  use a different signature mechanism, but he was wondering how to 
  specify the parameters as Linked Data.
Manu Sporny:  So we were wondering if we should have a different 
  vocabulary for signatures
Manu Sporny:  That's the open question
Dave Longley:  We should probably have this in a different 
  vocabulary, we could keep the security vocab a little cleaner if 
  we did that. [scribe assist by Manu Sporny]
Dave Longley:  Of course, we would like to minimize the number of 
  signature mechanisms, so that implementations aren't complicated. 
  [scribe assist by Manu Sporny]
Manu Sporny:  The URL might change. [scribe assist by Manu 
  Sporny]
Manu Sporny:  Which would break backwards compatability. [scribe 
  assist by Manu Sporny]
Manu Sporny:  This would affect the URL for the graph signature 
  would change
Dave Longley:  We could keep it in the security spec for 
  backwards compatability. [scribe assist by Manu Sporny]
Manu Sporny:  We have some deployment with GraphSignature2012, 
  but it's not too much of a big deal
Manu Sporny:  Melvin's system is highly experimental, so the 
  question is whether or not we should put highly experimental 
  things into here... so should we add things to the signature 
  vocabulary as people need them
Manu Sporny:  Or only add if they are standards track
Dave Longley:  For experimental things, you can always use the 
  full URL - you could invent names or a prefix for it. It doesn't 
  have to go in the official document, but the implementations 
  would work if they understood the URL for the specific type of 
  signature that's being created. That's probably the way we should 
  go with that. [scribe assist by Manu Sporny]
Manu Sporny:  So, use the full URL for now? [scribe assist by 
  Manu Sporny]
Dave Longley:  We should probably not put it into the official 
  spec if it's still experimental. Melvin should probably just use 
  a full URL. [scribe assist by Manu Sporny]
Dave Longley:  He can use whatever he wants for the URL, and it 
  probably shouldn't point to the signature algorithms vocabulary. 
  [scribe assist by Manu Sporny]
Manu Sporny:  So, should we create it? [scribe assist by Manu 
  Sporny]
David I. Lehn:  Does IETF specify all of the things we need for 
  this?
David I. Lehn:  They have URNs for them?
Melvin Carvalho: Sounds good to me :)
Manu Sporny:  I think they just have a registry, i don't think i 
  saw that the last time i looked, we need a URL
David I. Lehn:  Out of curiosity, does the IETF thing specify the 
  algorithms already? [scribe assist by Manu Sporny]
Manu Sporny:  If they have it we should use it
Melvin Carvalho: Yes, my system is experimental ... ill be 
  testing over the next year i think
Melvin Carvalho: Openssl specifies a list of algorithms iirc
Manu Sporny:  If the IETF spec specifies URLs or URNs we should 
  use them, we need an identifier
Manu Sporny:  We should create a signatures vocab for these
Manu Sporny:  For now it will just have two entries, it won't 
  take long to set up and start using
Manu Sporny:  Any other thoughts on that?
Brent Shambaugh:  There are bitcoin URIs defined somewhere
Brent Shambaugh: 
  http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/?viewmonth=201403&viewday=6
Manu Sporny:  If you're talking about bitcoin URIs for a 
  particular type of signature we can use that, otherwise it may 
  just have more to do with specific URIs for bitcoin
https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki
Brent Shambaugh: https://en.bitcoin.it/wiki/BIP_0021
Dave Longley:  Yeah, these are URIs for bitcoin addresses
David I. Lehn: 
  http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25
David I. Lehn: Short strings there
Manu Sporny:  Yeah, so that's the problem, the JOSE spec just 
  uses strings
David I. Lehn:  I thought the xmpp people has a URN scheme too, 
  but i can't find the reference right now
Manu Sporny:  Here's how we'd probably do it, we'd specify the 
  URLs in the signature vocabulary and point to the JOSE spec to 
  indicate that's what we're talking about
Manu Sporny:  For example, The MelvinSignature2014 algorithm uses 
  the ES256 algorithm as defined here: 
  http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#appendix-A.1
Manu Sporny:  I think we did that in a couple of other specs, 
  does that sound like an acceptable plan?
Melvin Carvalho: Web crypto API also has a list of algorithms
Manu Sporny:  Problem w/ Web Crypto API is that none of them are 
  URLs. XML DSIG does have URLs, that's what we use right now. ok, 
  we can just use those XML DSIG URLs maybe ... if everything we 
  need is there
Melvin Carvalho: 
  http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#algorithms
Manu Sporny:  The WebCrypto API isn't a recommendation yet, so it 
  may be problematic to point at it
Manu Sporny:  Any concerns about the plan?
No concerns expressed by the group.
Manu Sporny:  Ok, moving on

Topic: Tim Holborn Request for User Stories

Manu Sporny: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0197.html
Manu Sporny:  On the mailing list, Tim said he thinks we need 
  some user stories... the question i have is "What's the 
  difference between a user story and a use case"
Manu Sporny:  The use cases are a single line summary of a user 
  story
Manu Sporny:  Once we figure out each use case we'll have a 1-2 
  paragraph user story to expand upon the one liner.
Manu Sporny:  With the use cases we have today, we want to decide 
  if we believe they are in/out of scope, then we'd hand them off 
  to as many people as we can in the Web Payments CG to write a 1-2 
  paragraph story about what the motivation for the use case is
Brent Shambaugh: https://web-payments.org/specs/source/use-cases/ 
  <--- i.e. Lars and Jude?
Manu Sporny: This is a user story: 
  https://web-payments.org/specs/source/use-cases/#simple-payment-links
Manu Sporny:  I think that's what we're shooting for and that's 
  at the top there
Manu Sporny:  Any other thoughts on that?
Dave Longley:  That's a generic user story, a more detailed 
  representation of the use case. It makes it more obvious about 
  what we're trying to support. [scribe assist by Manu Sporny]
Dave Longley:  He could have said that he wants "authentic" use 
  cases, but that's what we have now, we've got use cases from 
  humans so I think we want to do what Tim's suggesting. [scribe 
  assist by Manu Sporny]
Brent Shambaugh:  What does he mean by "engagement by what 
  webwewant.org?"
Timothy Holborn: Hey guys, I just got pinged about this, joining 
  the call via IRC.
Manu Sporny:  "Webwewant.org" is about making the web about a 
  fundamental human right, etc. and the question is how we'd take 
  that movement and direct it at this web payments stuff, but i 
  think tim would have to propose something there, the user stories 
  are elaborations of each use case, etc.
Timothy Holborn: My concern was that some members may not have 
  enough software development lifecycle / related experience to 
  consider all the facets relating to a use-case.
Timothy Holborn: Therein; the use-stories (meaning, their more 
  contextual) might help flesh that out, and find things we might 
  be missing
Timothy Holborn: So, your in the US, others in other ‘common-law’ 
  countries
Manu Sporny:  So i think Tim is agreeing, he wants us to spell 
  out what each use case means and get more input from local groups 
  around the world.
Timothy Holborn: So many different ‘local rules’ to things.
Manu Sporny:  From non-US/other localities that we don't have a 
  lot of input from today
Timothy Holborn: Re: human rights = web - so is the ability to 
  monitise work.  I think we want to encourage accessibility for 
  ‘value-adding’ via WWW…
Timothy Holborn: I was lucky to get a 60k projector out of 
  customs in UAE, I found out about some local taxes along the way, 
  etc.
Manu Sporny:  Yes, that's true (what tim said), does anyone thing 
  we haven't addressed tim's concerns with the user story stuff?
Manu Sporny:  The current plan is to take the use cases (the one 
  liners) and expand them out into 1-2 paragraph user stories, once 
  we've decided which use cases are in/out of scope
Manu Sporny:  And it will be an iterative cycle, and the hope 
  here is that multiple people on the mailing list will be writing 
  user stories based on the use cases
Timothy Holborn: We’ve got a fair bit on our plate atm.  any of 
  these process also have threats about becoming insular with the 
  concepts / language, etc.  by going out and seeking info from 
  related groups - we might come across new concepts / ideas / 
  issues…  gives us an administrative challenge.
Timothy Holborn: Broader community engagement

Topic: Organizing Web Payments Workshop Use Cases

Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
Manu Sporny:  How do we want to approach culling the use cases 
  down to a manageable set? What we could do is talk about each one 
  and give it a thumbs up/down, just go through the list like that, 
  see where the discussion takes us.
Manu Sporny:  We're trying to aggressively cull these down to a 
  basic set for the Web Payments IG.
Timothy Holborn: See 
  http://lists.w3.org/Archives/Public/public-webpayments/2014Apr/0185.html 
Timothy Holborn: I think that’s a very important attitude to 
  have.  
Brent Shambaugh: Also: 
  http://www.supplydemand.info/webpayments/Web_Payments_Use_Cases_Refactoring_2014_04_25.html
Dave Longley:  So long as we’ve got sufficient datapoints, to 
  understand what our requirements need to be. [scribe assist by 
  Timothy Holborn]
Dave Longley:  So we're just doing another iteration on 
  categorization?
Manu Sporny: Yes, let's start here - 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Identity
Manu Sporny: The first use case: "Personal vault/wallet can host 
  information/assets and issue ids useful for various things (e.g. 
  payments?)"
Manu Sporny: Note, the first iteration would probably only store 
  basic identity credentials and payment provider information
Manu Sporny:  I think we should assume Identity is in scope 
  unless the Payments IG decides otherwise
Manu Sporny:  So we need to understand what needs to happen with 
  Identity to make payments work on the Web'
Manu Sporny:  Kumar from mozilla is asserting that we don't need 
  to touch Identity at all for payments on the web
Manu Sporny:  And that's correct, but it means we don't really 
  add much value, you can't tie payments to identity without any 
  standard
Timothy Holborn: RWW / 
  http://www.w3.org/DesignIssues/CloudStorage.html are producing 
  potential “cloud storage” services.  i imagine interactions will 
  play-out between the groups.
Manu Sporny:  Tim, yes - this is in that same vein. Payments are 
  fundamentally about trust between two entities, and in order to 
  do a payment on the web, since you aren't face to face, you need 
  to be able to understand who the sending/receiving parties are, 
  if for no other reason for KYC and anti-money laundering for 
  banks
Timothy Holborn: KYC / AML can be done by activating an account 
  (which can be done via a banking interface, paying to set-up an 
  account, for example).
Manu Sporny:  That's mainly why identity is big for payments, but 
  identity is also big on the web in general (single sign on for 
  the web, etc. the education space also needs an identity 
  mechanism and a way to store personal information in the cloud in 
  a way that is under your control ... and that's all about 
  identity)
Timothy Holborn: Once that account is created however; the online 
  account needs to maintain trust
Brent Shambaugh:  What about anonymous payments?
Timothy Holborn: I see these as two seperate issues.
Manu Sporny:  We do want to support anonymous payments, but in a 
  lot of cases that won't work
Manu Sporny:  Due to various regulations, etc.
Manu Sporny:  Banks can't enable money laundering --- anonymous 
  for small payments can work, but not for large payments based on 
  current regulation, etc.
Manu Sporny:  But the anonymity and privacy are part of the 
  identity discussion
Timothy Holborn: Could support anon in terms of what the receiver 
  sees
Manu Sporny:  We want to maximize those things where transactions 
  don't require it
Brent Shambaugh:  Could you have an anonymous URI and not 
  attribute things to anyone?
Manu Sporny:  Yeah, you could share URLs between like a thousand 
  people, you could create anonymous URLs, you can't tie them to a 
  particular person, but have information associated with it like 
  age of the person so you know they can buy things/meet certain 
  regulations
Manu Sporny:  There are varying degrees that we want to support 
  here that are all part of the identity discusison
Manu Sporny:  Re: tim in IRC, we do want to support anonymity 
  w/respect to what the receiver sees as much as possible
Manu Sporny:  Keeping your details private from the merchant 
  where they don't need that information, etc.
Brent Shambaugh:  Yeah, today you give people your credit card 
  number and that's not good
Manu Sporny:  Yes, especially with a debit card
Timothy Holborn: One of the KYC / AML technologies i work with 
  http://www.isignthis.com/ can identify a person rather well, 
  rather quickly.
Timothy Holborn: That gets past the reg. issues.  
Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Identity
Dave Longley:  First use case should be changed, it's too high 
  level, it should be narrowed. [scribe assist by Manu Sporny]
Timothy Holborn: However; in a use-case, where a provider like 
  that is used; to do the authorisation for an online ‘crediential’ 
  how is that ‘crediential’ tied to the user on an on-going basis, 
  if the transactions relate to say - a crypto-currency, or a 
  e-contract - something that doesnt require another ‘get’ request 
  from a traditional banking account.
Manu Sporny:  So, the use case should become something like: 
  "Store basic identity credentials and payment provider 
  information on the Web in a way that is easy to share with 
  various merchants given authorization by the owner of the 
  identity, and that is easy to synchronize between devices." 
  [scribe assist by Manu Sporny]
Manu Sporny:  Basically, a read-write web storage mechanism. 
  [scribe assist by Manu Sporny]
Dave Longley:  One way to look at these Identity use cases is 
  through the lens of Initiating Payments or Digital Receipts -- if 
  it's related to that, it's likely in scope.
Dave Longley:  So, meeting this use case is required given that 
  you'd need something like it to initiate a payment. If you're 
  storing digital receipts with your identity, that requirement 
  would make this use case in scope as well. Obviously, supporting 
  this will have applicability to use cases outside of payments. 
  [scribe assist by Manu Sporny]
Dave Longley:  We clearly need to support this use case because 
  it makes the whole initiating payment and digital receipts use 
  cases easier to achieve. [scribe assist by Manu Sporny]

PROPOSAL:  Accept the following use case - "Store basic identity 
  credentials and payment provider information on the Web in a way 
  that is easy to share with various merchants given authorization 
  by the owner of the identity, and that is easy to synchronize 
  between devices."

Dave Longley: +1
Manu Sporny: +1
David I. Lehn: +1
Brent Shambaugh: +1
Timothy Holborn: +1

RESOLUTION: Accept the following use case: Store basic identity 
  credentials and payment provider information on the Web in a way 
  that is easy to share with various merchants given authorization 
  by the owner of the identity, and that is easy to synchronize 
  between devices.

USE CASE: Store basic identity credentials and payment provider 
  information on the Web in a way that is easy to share with 
  various merchants given authorization by the owner of the 
  identity, and that is easy to synchronize between devices.

Manu Sporny: Looking at the second use case under identity - 
  "Managed access to personal identity/attributes as economically 
  valuable assets in a payment system"
Manu Sporny: Noting that the first iteration would probably not 
  focus on the "economically valuable" dimension of the personal 
  identity attributes
Dave Longley:  I don't see the difference between this use case 
  and the previous one. It's just the ability to manage whatever 
  credentials that you have. [scribe assist by Manu Sporny]
Manu Sporny:  Suggest that we strike this use case since it's 
  covered by the previous one. [scribe assist by Manu Sporny]
Timothy Holborn: +1
Timothy Holborn: Add it as a note to the first one
Brent Shambaugh:  What is "economically valuable"?
Manu Sporny:  "Economically valuable" means that storing 
  something like your spending habits would be valuable to someone 
  like Walmart -- and you could potentially have the ability to be 
  able to sell that information to them, etc.
Timothy Holborn: Birth certificate, passport, contract, important 
  email, 
Manu Sporny:  We should be able to build that use case on top of 
  what we have
Brent Shambaugh: +1
Brent Shambaugh:  But it's not required now
Timothy Holborn: Perhaps an ontological method to assert 
  something has a value.  bit like creative commons, 

PROPOSAL:  Fold the second identity use case ("Managed access to 
  personal identity/attributes as economically valuable assets in a 
  payment system") into the first one, since it consists of largely 
  duplicated information. Do not attempt to address "sale of 
  personal information" in the first iteration of the technology, 
  but keep it in mind while designing the core architecture.

Dave Longley: +1
Manu Sporny: +1
Timothy Holborn: +1
David I. Lehn: +0.5
Brent Shambaugh: +0.9

RESOLUTION: Fold the second identity use case ("Managed access to 
  personal identity/attributes as economically valuable assets in a 
  payment system") into the first one, since it consists of largely 
  duplicated information. Do not attempt to address "sale of 
  personal information" in the first iteration of the technology, 
  but keep it in mind while designing the core architecture.

Timothy Holborn: I think it should be noted in relation to the 
  first use-case that it is the intention of that use-case, to 
  support both
Manu Sporny:  As we approve use cases we should throw each 
  approved one to the mailing list to have someone write a user 
  story on the mailing list for each one
Manu Sporny:  Once the user story is written we can integrate 
  into the use cases document so there's a steady stream of 
  updating the use cases.
Manu Sporny:  Anything else before we go?
No other business, meeting adjourned.
Received on Wednesday, 30 April 2014 16:54:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:36 UTC