Re: credential based login

On 23 March 2015 at 08:09, <Axel.Nennker@telekom.de> wrote:

> 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.
>

I would encourage you to refrain from using the term "best" in this type of
discussion.  There are many forums that discuss identity, and everyone has
their favorites.

That said, I've followed IIW for many years, tho attending the conference
itself is out of my price range, much good work has come out of it.


>
> 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/
>
>