Re: Strong authentication for PayPal versus WebPayments

On 05/11/2014 07:08 AM, Anders Rundgren wrote:
>> We have this proposal on the table to address the NASCAR login 
>> problem, transmit payment provider details, and provide solid 
>> multi-factor authentication:
>> 
>> http://manu.sporny.org/2014/credential-based-login/
>> 
>> Outlining the problems that you see with that approach would be 
>> more helpful.
> 
>> From my point-of-view there's only problem: I don't understand how 
>> this
> would be and how it could address the NASCAR login problem :-(

We hope to have a demo with public source code in a few weeks to show
how this could work. In the meantime, I'll try to explain it below.

Identity Providers, Web Payments, and N-factor Authentication
-------------------------------------------------------------

We should all remember that N-factor (U2F, 2-factor, 3-factor, etc.) is
a security measure that is best when used in concert w/ an identity
provider or a web payments solution. We shouldn't conflate the use of
N-factor authentication with the ability to make a payment. You don't
need N-factor authentication to do a payment, any more than you need NFC
to do a payment. Both of those technologies would make the entire
process more secure and easier to perform, but it's important to not
conflate the technology stacks.

With that in mind, let's remove 2-factor authentication from this
particular discussion as it confuses the issue and doesn't have much to
do with the NASCAR login problem.

Addressing the NASCAR Login Problem
-----------------------------------

A good solution to the NASCAR login problem should have at least these
properties:

1. It should be privacy-aware.
2. It should allow you to switch from one identity provider to another
   with low switching costs.
3. It must be simple to implement on websites, preferably via a small
   JavaScript library.
4. It must have the ability to eventually be built into the browser to
   make the ecosystem even more secure.
5. It levels the playing field among identity providers and
   enables a large array of consumer choice between identity providers.
6. It can discover who your identity provider is given a simple piece
   of information that most people can remember.

Here are a few of the login solutions that we have today, and the goals
above that each one of them addresses:

OpenID 1.0      : #3, #5
OpenID Connect  : #3, #6
Persona         : #1, #3, #4, #6
Open Credentials: #1, #2, #3, #4, #5, #6

How it Works
------------

Here's what the Open Credentials login process looks like (right now,
it's still under development):

1. Website provides a "Sign In" button.
2. The browser displays a pop-up login screen on a login mixnet
   requesting email + passphrase. This step can be done in the
   same way that Persona did it - a shim that doesn't require any
   browser buy-in in the beginning. The login mixnet is required
   to ensure that your identity provider can't track which sites
   you're logging in to and sending your private information to.
3. The user types in their email and passphrase. A hash is created
   from the email and passphrase and a query is sent to a
   Telehash network (DHT-based decentralized network). All identity
   providers are connected to this network, and your one is looking out
   for a particular query matching the hash you generated. Once it
   detects it, your identity provider responds with an encrypted
   chunk that is then decrypted using the passphrase.
4. The decrypted chunk contains a private key that can then be used
   to counter-sign data sent from the identity provider.
5. Since we're doing a login, an assertion is sent from the
   identity provider to the login mixnet that proves that the person
   that's logging in has access to the email account. The private key
   on the login mixnet page is used to counter-sign the email
   assertion and that is relayed via the login mixnet to the
   receiving website (this is almost exactly how Persona works, btw).

The benefit gained by using the Open Credentials spec vs. Mozilla
Persona is that it enables the following three extra things:

1. It allows you to send any arbitrary credential (name, shipping
   address, passport, etc.), not just an email credential.
2. It should allow you to switch from one identity provider to another
   with low switching costs. (if we use a distributed ID mechanism to
   capture the credential assertions, we're still trying to figure out
   the best way to do that). The problem w/ switching IdPs today is
   that you can't take your identity URL with you.
3. It allows you to register your email address with any identity
   provider. Which means you can take your email address, and
   your identity URL with you.

This solves the NASCAR problem because the identity provider lookup
process is completely decentralized via Telehash. If you don't like the
idea of using a decentralized network like Telehash to do these lookups
today, then keep in mind that Telehash is just a stepping stone to
having this stuff in the browser (as was intended for Mozilla Persona).

Anders, I'm sure this email has raised more questions than it has
answered, and I've purposefully not included a number of details to try
and make the email shorter and easier to digest. If you have any
follow-up questions, I'd be happy to answer them.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Thursday, 15 May 2014 21:18:37 UTC