credential based login

Hi Manu, 

I would like to recommend the Internet Identity Workshop
 http://www.internetidentityworkshop.com/

 https://www.eventbrite.com/e/internet-identity-workshop-xx-20-2015a-tickets-14097972415 
next month in Mountain View, California.

It is the best place to discuss all ideas around identity.

Kind regards
Axel

https://www.w3.org/community/credentials/



-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: Monday, March 23, 2015 4:24 AM
To: public-credentials@w3.org
Subject: Re: Leveraging DNS and email addresses

On 03/16/2015 04:02 AM, Adrian Hope-Bailie wrote:
> I have been thinking lately about the challenge of keying an identity 
> in a way that:
> 
> * Is easy to transfer and remember (even for humans) * Can be 
> normalised in a standard way and used as part of a standardised 
> discovery process by a client to discover the Identity Provider
> (IdP) for that identity

We've been doing quite a bit of thinking in this area for years, some background reading on the current status of this thinking:

http://manu.sporny.org/2014/credential-based-login/

http://manu.sporny.org/2014/identity-credentials/


The rest of this post assumes you've read the blog posts above.

> To my mind the obvious solution is to use the email address format as 
> this is already a well-known standard which user's understand.

+1 to using email addresses as the /keying/ mechanism used to discover
an IdP.

-1 to making the IdP the same domain as the email address. Doing that creates a monopoly (Google for gmail.com addresses, for example).

-1 to using email addresses as the thing that you tie a credential to - doing that leads to monopolistic behavior. Tying a credential to anything that's not completely portable and under the recipients control is ceding control of that credential to someone other than the recipient.

> It seems to me that the only argument against an email address format 
> is that the domain part is often not under the control of the  
> identity owner. I don't see that is a good enough reason to force 
> users to try and change their thinking and use URIs as their 
> identifiers.

That's the wrong way to look at it - the fact is that /both/ email addresses and URLs are bad things to tie credentials to. Email addresses are good as a lookup mechanism because it's been proven that people can remember them easily. URLs are bad as a lookup mechanism, and they're bad as a thing to tie credentials to, but they're good for hanging machine-readable information off of.

> I don't have statistics to back this up (perhaps somebody does) but I 
> consider the relative obscurity of OpenID as a login option as 
> evidence that this is a bad idea.

Yep, OpenID URLs are a bad idea.

> So how do we help the user that has an email address @gmail.com 
> <http://gmail.com> or @hotmail.com <http://hotmail.com> or @yahoo.com 
> <http://yahoo.com> but wishes to host their identity themselves or at 
> a different IdP?

Yep, exactly the question you should be asking.

> First, we define a mechanism or standard algorithm/protocol for 
> translating their email address into a service discovery process that 
> may start with their home domain but ultimately result in the client 
> accessing the identity somewhere else. Then we pressure the large 
> email providers to abide by this standard. I acknowledge that this may 
> be difficult but I would say it is not impossible.

That's what Mozilla Persona was about, and it failed. The blog posts above explain why Persona failed.

> I imagine the user experience being something like the following:
> 
> 1. I log in to my account with this email provider, go to my account  
> settings and provide the URL of my IdP. 2. When I use my identity 
> online the client executes the service discovery protocol as defined, 
> contacts my email provider and is given the URL I have configured as 
> part of this process. 3. The client negotiates with my IdP of choice 
> to get my identity information.

You've basically re-invented Persona and added a redirection mechanism, and I don't think that'll work.

> If we have designed the protocol correctly (very close to what is 
> already in place today) my email provider only knows who my IdP is but 
> nothing more about the identity I have defined their unless I choose 
> to share it.

Why would Google adopt this for gmail.com? What's in it for them? Same question goes for all the major email providers.

> Where a user has a primary email address with a provider who is not 
> following the standard the user has two choices:
> 
> 1. Change email providers

I don't think people with a gmail.com address will do this.

> 2. Use an identity that is different from their primary email address.

I don't think people will understand why they have to have two email addresses.

> Is there a compelling case for using a URI as an identity key as 
> opposed to the familar form of an email address?

Email addresses change throughout your lifetime. Tying identity to a URL is also a bad idea. The world needs a decentralized identifier that's portable, full stop. The blog posts go into it a bit more... the identus.org demo is something you should look at... I'd be happy to go through it w/ you at some point.

-- 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 Monday, 23 March 2015 07:09:58 UTC