Re: Web Payments Telecon Minutes for 2014-03-19

On 19 March 2014 19:21, <msporny@digitalbazaar.com> wrote:

> Thanks to Evan Schwartz for scribing this week! The minutes
> for this week's Web Payments telecon are now available:
>
> https://web-payments.org/minutes/2014-03-19/
>
> 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-19
>
> Agenda:
>   http://lists.w3.org/Archives/Public/public-webpayments/2014Mar/0128.html
> Topics:
>   1. Web Payments Workshop Agenda
>   2. Web Payments Mobile Use Cases
>   3. Credential-based Login
>   4. HTTP Signatures Update
> Chair:
>   Manu Sporny
> Scribe:
>   Evan Schwartz
> Present:
>   Evan Schwartz, Manu Sporny, Brent Shambaugh, Matt Kaufman, Dave
>   Longley, Erik Anderson, David I. Lehn
> Audio:
>   https://web-payments.org/minutes/2014-03-19/audio.ogg
>
> Evan Schwartz is scribing.
> Manu Sporny:  Any changes to the agenda? *long pause* If not,
>   moving on.
>
> Topic: Web Payments Workshop Agenda
>
> Manu Sporny: http://www.w3.org/2013/10/payments/agenda.html
> Manu Sporny:  Agenda is almost finalized. ton of big
>   multinational companies and startups attending. only thing that's
>   weak at the conference is participation by retailers and
>   regulators
> Manu Sporny:  6 Sessions, each 2 hours, mostly attendee-driven,
>   main purpose of speakers is to kickstart discussion
> Manu Sporny: Session 1 -- Overview of Current and Future Payment
>   Ecosystems
> Manu Sporny: Session 2 -- Toward an Ideal Web Payment Experience
> Manu Sporny: Session 3 -- Back End: Banks, Regulation, and Future
>   Clearing
> Manu Sporny: Session 4 -- Enhancing the Customer and Merchant
>   Experience
> Manu Sporny: Session 5 -- Front End: Wallets - Initiating Payment
>   and Digital Receipts
> Manu Sporny: Session 6 -- Identity, Security, and Privacy
> Manu Sporny: Papers that were accepted are at the bottom of the
>   page: http://www.w3.org/2013/10/payments/agenda.html
> Manu Sporny:  Accepted papers for the workshop can be found on
>   conference page
> Manu Sporny:  Papers that were not accepted will not be shown on
>   the conference webpage because some of them were quite bad and
>   got bad reviews, authors that want theirs published can publish
>   them through other means
> Manu Sporny:  Conference starts next monday, fantastic group
>   coming to it
> Manu Sporny:  All of the minutes will be made public shortly
>   after, if not during the conference
> Manu Sporny:  Pindar has asked if we can record the video or
>   audio of the conference, we'll have to ask w3c
> Manu Sporny:  W3C might agree to it, unless the PC or attendees
>   don't want it to happen, or if there isn't the time to set it up
>
> Topic: Web Payments Mobile Use Cases
>
> Manu Sporny: Would you mind giving us an overview of the use
>   cases you've been collecting, Brent?
>   https://github.com/w3c-webmob/payments-use-cases
> Brent Shambaugh:
>   https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases
> Brent Shambaugh: https://github.com/w3c-webmob/payments-use-cases
> Brent Shambaugh: Due to discussions with Marcos Caceres and
>   Natasha Rooney am attempting to apply the following template:
> Brent Shambaugh: Name: name of the solution
> Brent Shambaugh: Use Cases: Key use cases for the solution
> Brent Shambaugh: Regions and currencies: Any SDKs or APIs which
>   are available to developers
> Brent Shambaugh: With the following things to consider (for use
>   cases):
> Brent Shambaugh: (1) Add real money to the service
> Brent Shambaugh: (2) Buy a physical good in the real wold (e.g.,
>   a cup of coffee)
> Brent Shambaugh: (3) Pay for physical service (e.g., gym
>   membership)?
> Brent Shambaugh: (4) Convert virtual money back into paper money
> Brent Shambaugh: (5) Transfer money from one person to another
>   (even if the second person is not signed up for the service)?
> Brent Shambaugh: (6) Buy product online
> Brent Shambaugh: (7) Resolve disputes?
> Brent Shambaugh: (8) View transactions?
> Brent Shambaugh: (9) Secure the wallet
> Brent Shambaugh: (10) Etc.
> Brent Shambaugh:  Right now i have a lot of information, trying
>   to fit it in a template
> Brent Shambaugh:  Next stage is to weeding stuff out, make it
>   more digestable
> Brent Shambaugh:  How the phone is communicating with other
>   devices, new hardware or legacy hardware, existing ACH system or
>   replace that entirely with bitcoin or ripple, start adding info
>   to transactions with payswarm and linked data or namecoin or
>   colored coin?
> Brent Shambaugh:  Emphasis towards trying to use the legacy
>   hardware, difficult to push people to use new stuff
> Brent Shambaugh:  Convert virtual money back into paper money --
>   might be a small use case
> Brent Shambaugh:  If you compare stripe and square, square has
>   POS system, stripe is only API no hardware
> Brent Shambaugh:  Many systems store reward card or store credit
>   card info in the system
> Manu Sporny:  Fantastic amount of info on the wiki page,
>   condensing all of the info down is easier than getting the info
> Manu Sporny:  Natasha was hoping we would have a summary to share
>   with the web payments workshop, need a bit more time to condense
>   it further
> Manu Sporny:  What are the common features across all of these
>   solutions, what could be standardized and what couldn't, combine
>   that with the CG's work and the workshop attendees input, we'll
>   have some authority to say we've done our homework
> Manu Sporny:  Can turn the use cases into spreadsheet of features
>   and solutions and just have check boxes for which solutions have
>   which services and tally the most widely spread features, only
>   problem is that may lose most innovative solutions
> Brent Shambaugh:  Do we care about listing hardware stuff too?
> Manu Sporny:  Might be good to outline hardware, educates us
>   about what's missing in mobile phones or devices, square reader
>   tells us that card readers are missing from mobile phones
> Manu Sporny:  Brent should brainstorm and send an email to the
>   mailing list about how to coalesce info into 1-2 page summary
> Manu Sporny:  Brent should talk to natasha about the most updated
>   list of use cases
>
> Topic: Credential-based Login
>
> Manu Sporny: http://manu.sporny.org/2014/credential-based-login/
> Manu Sporny:  Now that persona's engineers have been transitioned
>   off the project, we needed to at least propose something for
>   doing transmission of digital wallet provider info
> Manu Sporny:  Apply identity credentials spec to login on the
>   web. when you login to a website that you need to make a payment
>   on, the process used to transmit payment info should be the same
>   as transmitting address and login info
> Manu Sporny:  Email is one credential, shipping address is
>   another credential, where you live, age, etc
> Manu Sporny:  Use same method to transmit email as well as other
>   more complicated data, it's all transmission of credentials.
> Manu Sporny:  Proposal looked at reasons mozilla thought persona
>   failed other than internal problems. google and yahoo didn't want
>   to add persona support
> Manu Sporny:  Bypass the email providers so that a number of
>   organizations can digitally sign email address, no longer
>   beholden to email providers.
> Manu Sporny:  Persona had to run centralized infrastructure while
>   getting the system off the ground, and that cost mozilla a lot of
>   money/time.
> Manu Sporny:  Proposed decentralized solution based on telehash,
>   didn't know if telehash would work for this but after speaking w/
>   Jeremie Miller, he said it could support this login mechanism
> Manu Sporny:  Clearly there are problems with this proposal, but
>   the hope was that other people would specify what they would want
>   to replace parts of the system with
> Manu Sporny:  Decentralized system could be replaced by any
>   decentralized network, namecoin, other distributed hash table
>   solutions
> Matt Kaufman:  Is anyone aware of google migrating to google+
>   single sign-on? They have a timeline migration table here:
>   https://developers.google.com/+/api/auth-migration
> Matt Kaufman:  Why wouldn't the PGP system work for the public
>   key? Maybe with keys stored in DHT?
> Manu Sporny:  Making it a little more web-y, trying to remove
>   centralization, login assertions are digitally signed using
>   public-private key crypto. we're using email because the system
>   has to work for people that don't understand crypto. if using an
>   email need a way of mapping email to identity
> Manu Sporny:  System should be online at all times, could use DNS
>   system and make sure that core identity servers are up all the
>   time, but then there needs to be central organization that
>   maintains system
> Manu Sporny:  Jeremie Miller has recently picked up telehash full
>   time, he always wanted xmpp to be decentralized
> Manu Sporny:  If we want attack resistant network, bit torrent
>   uses kademlia, mpaa has tried many times to kill it and it hasn't
>   worked
> Manu Sporny:  Very attack resilient
> Manu Sporny:  Another network like bitcoin could do it as well
> Manu Sporny:  Need to bridge those non-web protocols to the web
> Manu Sporny:  User should be able to decide when to share or not
>   share info
> Matt Kaufman:  Nxp has ucode gen2 chip, nfc rfid chip with
>   integrated i2c - do we care about that sort of hardware? Is that
>   out of scope?
> Manu Sporny:  We do want to support two factor authentication, or
>   three factor authentication, but we can't count on it being in
>   every device so we leave that up to identity provider.
> Manu Sporny:  If they trust no one they can setup their own
>   system
> Manu Sporny:  People will pick identity providers based on
>   security and ease of use
> Evan Schwartz:  Is the idea that you'd store actual credential
>   data in the Kademlia DHT? Do you only store the latter, just
>   store the mapping? [scribe assist by Manu Sporny]
> Dave Longley:  You'd do the latter, right now. Mapping from email
>   to identity provider, primarily. [scribe assist by Manu Sporny]
> Manu Sporny:  There is a potential future here where you'd store
>   all credentials in the cloud. [scribe assist by Manu Sporny]
> Matt Kaufman:  How will the DHT first be populated?
> Manu Sporny:  Go to some website, go to another that will do
>   email verification, now that website will digitally sign that
>   email is tied to your identity
> Manu Sporny:  Information is stored at identity provider and then
>   send something to telehash network, everything is encrypted so if
>   you need to login to a website you type in email address and
>   passphrase, query goes to telehash network and if the passphrase
>   is correct then it's used to decrypt identity service. Identity
>   service verifies the email verification and sends it to the
>   website.
> Manu Sporny:  This is a very loose plan right now, there are a
>   number of security concerns and usability/centralization
>   concerns.
> Evan Schwartz:  I'm pretty interested in how to move away from
>   everything being stored by an identity provider. I don't like the
>   idea of depending on a specific service. If they're down, or
>   they're out of range/firewalled, or they're trying to block me,
>   that's not good. [scribe assist by Manu Sporny]
> Evan Schwartz:  How does this system prevent the IdP from
>   impersonating me to a different service? How do you prevent the
>   IdP's from impersonating you. [scribe assist by Manu Sporny]
> Brent Shambaugh: An improvement on DHT:
>   http://iptps06.cs.ucsb.edu/papers/Pouw-Tribler06.pdf,
> Brent Shambaugh: Another improvement (INGA)
>
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.7668&rep=rep1&type=pdf
> Brent Shambaugh: Use semantic information in the network
> Dave Longley:  In the future, an IdP could always come along and
>   provide it's own decentralized solution that piggybacks off of
>   this. They could store stuff in the decentralized cloud that
>   avoids this sort of stuff. So, there could be innovation built on
>   top of this. [scribe assist by Manu Sporny]
> Dave Longley:  An identity provider could come along and store
>   their info in a decentralized cloud
> Erik Anderson:  Anything I need to know about this before the
>   workshop?
> Manu Sporny:  No, but we can talk about it there if necessary.
>
> Topic: HTTP Signatures Update
>
> Manu Sporny:  This stuff is important for banking and verifying
>   high value transactions
> Manu Sporny: Mark Nottingham and Julian Reschke gave us some good
>   input recently, offlist.
> Manu Sporny:  They were positive but http auth working group is
>   shutting down in 3 months, but they have offered to make it part
>   of http bis working group if necessary.
> Manu Sporny:  Proposed way to simplify spec for authorization and
>   non-authorization scenarios
> Manu Sporny:  Could create new signature header, only adds 4-5
>   paragraphs to the spec
> Manu Sporny:  Clear ietf path and clear editorial path
> Manu Sporny:  This allows digital signature authorization on http
>   request, even without logging into a service
> Manu Sporny:  Integrates with identity credentials and json-ld
> David I. Lehn:  When should we start updating implementations?
>   Some of these are breaking changes, aren't they?
> Manu Sporny:  The only thing that should change in library
>   implementations should be addition of signature header
> Manu Sporny:  There are ways of making the code change without
>   breaking things that are out there
> Dave Longley:  Maybe all the changes could be done in a
>   deprecation manner and phased out over time
> Manu Sporny:  Ok, out of time for today. Next week is the Web
>   Payments Workshop, very excited about that. No call next week,
>   we'll pick up again to do a post-workshop wrap up in the first
>   week of April... April 2nd is the next call.
>

Thanks for the minutes and blog post, I'm trying to understand the telehash
dependency better.

Is the use case that a user types in an email address into a form, and you
wish to get an HTTP URL from that?

Something wasnt 100% clear for me from the blog, might the user also need a
15 character password.

PS: dont expect a long answer to this, feel free to reply with a couple of
words, or save it until after the workshop :)