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

Web Payments Telecon Minutes for 2014-03-05

From: <msporny@digitalbazaar.com>
Date: Wed, 05 Mar 2014 13:51:59 -0500
Message-Id: <1394045519666.0.27841@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:


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-03-05

  1. Web Payments Mobile Use Cases
  2. Persona and Web Identity Spec
  3. Decentralized Credentials-based Login
  4. HTTP Signatures
  Manu Sporny
  Dave Longley
  Dave Longley, Natasha Rooney, Manu Sporny, Erik Anderson, David 
  I. Lehn, Brent Shambaugh

Dave Longley is scribing.

Topic: Web Payments Mobile Use Cases

Manu Sporny: https://github.com/w3c-webmob/payments-use-cases
Natasha Rooney:  Hi Natasha from GSM Association, big mobile 
  standardization organization, Brent has offered to help out on 
  mobile payments use cases, what we're doing is taking use cases 
  for how payments exist on native platforms, possibly in 
  proprietary solutions on the web, and documenting how they work 
  on mobile
Natasha Rooney: 
Natasha Rooney:  Thx for putting up link to github page, there's 
  also a wiki, the work is in two places, i'd like to move both 
  into github, my preference
Natasha Rooney:  Or continue to work on the wiki, the issue there 
  is that the mobile access group doesn't have access to the wiki
Manu Sporny:  The wiki was meant to be temporary, we didn't want 
  20-30 PRs out there conflicting, we wanted a rapid way to dump 
  information in there, and then organize and move back to github
Manu Sporny:  If you feel there's enough information there please 
  pull it back into github
Manu Sporny:  There are some outstanding questinos there we'll 
  get to later
Manu Sporny:  We wanted to be able to iterate on it quickly and 
  github PR was maybe going to slow it down
Natasha Rooney:  Makes perfect sense, i'll pull things into 
  github repo
Natasha Rooney: https://github.com/w3c-webmob/payments-use-cases
Natasha Rooney:  I went through the wiki style use cases, got 
  criticized by co-chair saying we really should document solutions 
  that exist across native platforms, and that experience on 
  mobile, if you scroll down to the paypal section on github, 
  there's an example of what i'd like to produce for all of the 
  other native applications/plugins/proprietary apps
Natasha Rooney:  I've put in regions where it operates, 
  capabilities, APIs to develop
Natasha Rooney:  I consider API very interesting as something we 
  could use as a standardization body to create an API later on, 
  not wanting to get into a legal discussion now there are legal 
  issues, just a good guideline
Natasha Rooney:  We'd like help from both this group and the rest 
  of the mobile interest group as well, we want a robust set of use 
  cases for payments for mobile
Natasha Rooney:  Manu you mentioned questions?
Manu Sporny:  I think you answered a good chunk of them, the main 
  thing we were concerned about -- some of the use cases weren't 
  use cases but feature sets, some people disagree on what "use 
  case" means.. don't want to get bogged down there... so we've 
  been taking any use cases we can see from websites for payment 
  providers and also pulling any features that seem important but 
  can't be categorized as use cases and documenting those too. Your 
  developer API sections make more sense to me now, might be 
  difficult to get all that information together before W3C Web 
  Payments Workshop.
Manu Sporny:  The high-level question is .... it's confusing how 
  we should categorize mobile payments use cases vs. just web 
  payments use cases, because as you said there's a lot of overlap, 
  so in general we've been trying to capture everything and then we 
  can pull the mobile bits out of everything, the reason for 
  capturing everything is that we dont' have a document outlining 
  all the payment systems out on the web today so this would be  a 
  good opportunity to do that, and at the same time we'd get the 
  mobile use cases
Manu Sporny:  In particular did you have a way that you wanted to 
  classify the mobile payments stuff? What qualifies a mobile 
  payments system
Natasha Rooney:  I was taking the approach of everything as well, 
  focusing on everything means there's a lot of work to do, but not 
  focusing on it and thinking just focusing on the desktop issue 
  may cause issues later on, think of this instead as a 
  data-gathering exercise and then from that data identify the use 
  cases, so when i looked at google wallet and paypal there was a 
  common set of use cases
Natasha Rooney:  So i think one doc for data and then have 
  another doc that identifies use cases and put data underneath it 
  would work
Manu Sporny:  Yeah, my concern is getting something to the web 
  payments workshop that's useful, i feel we have a decent chunk of 
  work in front of us that could be reduced by just doing a fairly 
  high-level pass of these systems
Manu Sporny:  We still capture a good chunk of common use cases
Manu Sporny:  For example, being able to pay with a digital 
  wallet that supports credit card and bank account
Manu Sporny:  We have a lot of these payment mechanisms out there 
  on this web payments mobile use cases page, but if we do just a 
  really quick scan across the site, 10-15 minutes per platform we 
  can get a good high-level summary of the types of features that 
  there are, we won't be able to get deep into development API, but 
  we can get what each site thinks are the most important features 
  that they provide, that way we can get this done in the next week 
  hopefully and then there's a week left to get things down to 
  something the workshop can use
Natasha Rooney:  Makes sense i can find key cases that exist 
  between them
Natasha Rooney:  I forget how close it is to the workshop
Natasha Rooney:  After this call, i'll do that email to both 
  groups about what we're going to do now and hopefully we'll get 
  some people to help brent and me out here
Natasha Rooney:  Feel free to raise an issue on the github repo, 
  if you have a particular thought, don't feel you'll have to deal 
  with it, if you're silent we won't know about it, please be vocal
Manu Sporny:  Let's say the deliverable to the workshop is the 
  first iteration of the use cases, after that the CG will want to 
  go back in an expand out each of the high level things, we'll 
  want to do a deep dive into dev APIs for types of calls they 
  provide, things like that, do you want to coordinate through the 
  payment use cases thing throuhg the web and mobile group or do 
  this somewhere else? seems this will turn into a living doc on  
  all the payment systems out there, i'm happy to put it in the 
  payments use cases repo, if you think that's something the web 
  and mobile group would be interested in to collaborate on.
Natasha Rooney:  Yeah, i think you guys should eventually pull it 
  in, it can stay where it is now, but you guys can pull it over 
  later it would be best
Natasha Rooney:  We can still work on this with you guys of 
  course, you can always get me to join a call, we can have that 
  discussion about what other work needs to be done
Manu Sporny:  The rough plan then is to get as many people as we 
  can get to keep fill out the use cases wiki, preferably following 
  the format of the paypal example in the github repo (payments use 
  cases repo) and once we're done filling that out, you (Natasha) 
  will pull the pieces you think are applicable to mobile payments 
  into the github repo and do some editing there, and whatever that 
  doc ends up becoming it's one we will provide to the web payments 
Manu Sporny:  After the workshop, we'll figure out a way of more 
  properly getting all the information together and maybe we'll put 
  it into a respec format or github repo or something and continue 
  to add deeper info about dev APIs and other things that aren't 
  quite apparent at first glance from lookign at this websites, 
  that sound good?
Natasha Rooney:  Absolutely perfect, you've got it all
Erik Anderson:  No input from me, all good discussion
Natasha Rooney:  I have to run, but it sounds good

Topic: Persona and Web Identity Spec

Manu Sporny: https://web-payments.org/specs/source/web-identity/
Manu Sporny:  The spec's been worked on for a while now, the spec 
  covers ways to identify people, home address, KYC, email, payment 
  systems and banks need this info, the web identity spec defines a 
  mechanism for storing that info and retrieving it in a 
  decentralized way
Manu Sporny:  When you log into a website you can provide your 
  home address, credit score, govt ID, etc. in a way that's 
  digitally signed, your govt ID for example could be signed by 
  your national govt and your bank could depend on it 
Erik Anderson:  I have a call with the Department of State later 
  on this week concerning this subject
Manu Sporny:  We're also working with an entity in the education 
  arena and they have millions of identities that they have to 
  identify on a yearly basis... they have to ensure people have 
  university degrees, make sure people have credentials to do 
  surgery on people, practice medicine as a nurse, things of that 
Manu Sporny:  This is cryptographically verifiable identity 
  stuff, where it really matters if that doctor that is going to 
  operate on you is qualified, or that multi-thousand dollar 
  transaction you're going to do is actually approved by you, etc.
Manu Sporny:  We've been operating with this name "Web Identity" 
  for a while now which is confusing because there are other 
  identity specs out there, this spec is more about verifiable 
Manu Sporny:  The idea to rename the spec to "identity 
  credentials" or "web credentials" or "entity credentials" has 
  been floated
Manu Sporny:  The idea here is to help people understand that 
  while identity is an aspect of this it has more to do with 
  verifiable credentials than not
Manu Sporny:  I think the current proposal is "web credentials" 
  or "identity credentials"
Erik Anderson:  "Digital credentials" works too
Manu Sporny:  Stephen rowat pointed out that "web" isn't that 
  useful in the name
Manu Sporny:  "Digital" is sort of like "web" here, doesn't add 
  all that much
Dave Longley:  I agree that "identity credentials" is better. 
  [scribe assist by Manu Sporny]
Erik Anderson:  "Identity credentials" ... people want to be 
  anonymous on the web, could bring library of congress in - lots 
  of people do identity, you want to show up well on searches.
Erik Anderson:  Might be hard to find (too generic)
Manu Sporny:  We do want the name of the spec to be fairly unique
Manu Sporny:  "Digital credentialing" is pretty well-used term as 
Dave Longley:  "Decentralized Credentials" ?
Erik Anderson:  I like that, it's ok
Manu Sporny:  Yeah, that's ok
Erik Anderson:  I have to drop off, another call
Manu Sporny:  We'll send the new name to the mailing list to see 
  if anyone objects
Manu Sporny:  We had some spec changes, most recent change is the 
  login mechanism that was just added

Topic: Decentralized Credentials-based Login

Manu Sporny: A commit was made yesterday to the "Decentralized 
  Credentials" specification adding a Persona-like login mechanism: 
Manu Sporny: The section can be viewed here: 
Manu Sporny:  The spec provides a way to assert facts about 
  yourself, the same mechanism can be used for login, now that 
  persona is on the backburner at mozilla, we're back to not really 
  having a unified login mechanism other than OpenID connect, and 
  while we could use Decentralized-Credentials-based login using 
  OpenID connect, the flow is not ideal, the other issue with 
  OpenID connect is that there are something like 17 specs you need 
  to implement to get it working, it's not trivial to implement to 
  do a login. Persona by comparison was fairly trivial to 
  implement, especially if using secure messaging instead of the 
  JOSE stack.
Manu Sporny:  So what was added to DC spec was an example of 
  login mechanism, so if you don't have openID or persona then you 
  can still do a login, it's a fairly simple 2-step process
Manu Sporny:  The other thing that this new login flow does is 
  ... it can operate as a replacement for persona, it's a much more 
  simplified version for persona, it also means there can be a 
  browser polyfill for it, using a regular desktop, tablet, etc you 
  can do an email-based login
Manu Sporny:  Looks like this: customer goes to a store to make a 
  purchase, type in/auto fill email, and if they have the browser 
  implementation then they'll log right in. If they don't, then the 
  polyfill will contact a 3rd party identity login service that 
  looks just like Persona.
Manu Sporny:  It's a fairly nice way of doing login, with one 
  exception in that 3rd party app could find your ID using a 
  decentralized protocol
Manu Sporny:  We're looking at using telehash for the 
  decentralized bits of it.
Manu Sporny:  So all the identity providers don't have to be tied 
  to a single third party
Manu Sporny:  They just join a decentralized network
Manu Sporny:  If you dont' have browser impl. then 3rd party 
  network finds your ID provider and store talks to them and gets 
  digitally signed ID+email (that credential)
Manu Sporny:  Your credential could be stored on a completely 
  different identity provider, etc. it's fairly complicated behind 
  the scenes but the customer it just is a quick login with browser 
  support or not.
Manu Sporny:  What the store gets is a digitally-signed assertion 
  that you have that email address,  which is what persona does 
  right now.
Manu Sporny:  Since we're also talking about payments here, what 
  we also want is to send your preferred payment provider to the 
  store, so the credential will include verified email and payment 
Manu Sporny:  Other things in the future could include, email 
  address, preferred payment provider, and shipping address when 
  logging into amazon, for instance, etc
Manu Sporny:  Dave Longley, we may want to talk a bit more about 
  the telehash-based mechanism
David I. Lehn:  Why are we considering telehash?
Dave Longley:  At a high-level the telehash based mechanism - 
  decentralized network - makes it easy to discover nodes on a 
  decentralized network. Individual identity providers would 
  generate a hash and join a network. Any queries that came across 
  the network for various credentials would return which identity 
  provider could provide the credentials. We want an authentication 
  layer on top of this. [scribe assist by Manu Sporny]
Dave Longley:  We need to think through the authentication layer 
  a bit more. Basic idea is that authenticated requests for given 
  email address. Other credentials could be used. Decentralized 
  network would respond w/ which identity provider handles which 
  email address. [scribe assist by Manu Sporny]
Dave Longley:  If you have a browser implementation, it provides 
  the login information directly. If you don't have a browser 
  implementation, you ask the decentralized network. [scribe assist 
  by Manu Sporny]
Manu Sporny: So, in general, you go to the store and put in your 
  email address. That store calls 
  'http://example.com/login-callback'). In the browser-native 
  implementation, that would create a dialog where the user picks 
  which identity they want to use to login, the email credential 
  verifying that you own the email address is retrieved from the 
  identity provider, and the credential is delivered to the 
Manu Sporny: In the non-browser-native implementation, the 
  polyfill would open a browser window to a trusted, open source 
  login aggregation site (jointly run by W3C, Mozilla, and IETF).  
  That site would hook into the telehash protocol, retrieve your 
  email-to-identity-provider mapping (protected via a password to 
  prevent information leakage), and use that to map the email to 
  the identity provider. The rest of the interaction would be the 
  same as the browser-based mechanism above. Note that this step is 
  done to ensure that the identity provider doesn't know where 
  you're using each credential (tracking protection).
Dave Longley:  We might be able to implement this where the store 
  would just have a javascript telehash client, which just runs in 
  your browser. Browser connects and gets your identity provider. 
  [scribe assist by Manu Sporny]
Manu Sporny:  There are of course, privacy issues w/ that 
  approach - namely that each store would know who your identity 
  providers are (and that's probably not a good thing).
Dave Longley:  Since the telehash client is a javascript client, 
  you can talk more closely with the browser. Maybe there is 
  something clever we can do w/ the authentication there - 
  leveraging Web Crypto for one-time pads. The information that you 
  use is only in localstorage for that site. There are some 
  implementation details that we need to think through, but that we 
  can use a javascript telehash client means that we may be able to 
  solve the privacy issues as well. [scribe assist by Manu Sporny]
Manu Sporny:  We can always fall back to a 3rd party site to do 
  the implementation, like Persona did.
Dave Longley:  It is fully decentralized, but we provide a 
  mechanism to ease implementation. [scribe assist by Manu Sporny]
Manu Sporny:  We don't want identity providers to be able to 
  track you across the web, there's a debate about whether or not 
  that's ever possible, etc. evercookies, google tracking, etc. 
Manu Sporny:  However,  that's another concern and we'll get to 
  that in time. The solution is simpler than OpenID Connect and 
  requires less of a technology stack (and infrastructure) than 

Topic: HTTP Signatures

Manu Sporny: 
Manu Sporny:  We've gotten good feedback from some folks working 
  on HTTP/2 and HTTPbis
Manu Sporny:  We've made updates based on mark nottingham and 
  julian reschke's feedback
Dave Longley:  We should also make sure to review this (looks 
  more or less like what we ended up with): 
Dave Longley:  And this, which was abandoned: 
Manu Sporny:  The other thing that's interesting with the 
  signature stuff is that the Authorization header that is meant to 
  be client-server, http is written such that the client and server 
  can switch places, and that's perfectly fine, the problem is in 
  including Authorization header in an http response
Dave Longley:  I believe that Content-Signature might not be the 
  right thing... maybe just "Signature" header? [scribe assist by 
  Manu Sporny]
Manu Sporny:  If we do that, should we have the Authorization 
  header? [scribe assist by Manu Sporny]
Dave Longley:  If we do that, we should abandon Authorization, or 
  put it in another specification. [scribe assist by Manu Sporny]
Dave Longley:  Maybe Authorization should be for sessions only? 
  [scribe assist by Manu Sporny]
Manu Sporny:  Maybe we'll put Authorization into a different 
  spec, and Signature header into a different spec? Authorization 
  builds off HTTP Signature Header spec? [scribe assist by Manu 
Dave Longley:  That allows us to make a number of changes w/o 
  breaking backwards compatibility. [scribe assist by Manu Sporny]
Dave Longley:  If they're just using the Signature header, 
  they're using the new mechanism. If they're using it in the old 
  way, it either won't function or it won't be supported. [scribe 
  assist by Manu Sporny]
Brent Shambaugh: Sorry that I did not make it to the beginning 
  part of the teleconference. Did it go well?
Brent Shambaugh: I just posted thoughts to the list. It might be 
  better there.
Manu Sporny: Yeah, posting to the mailing list is helpful, 
Received on Wednesday, 5 March 2014 18:52:22 UTC

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