W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Re: Leveraging DNS and email addresses

From: Erik Ros <mail@erikros.me>
Date: Thu, 26 Mar 2015 08:20:55 +0000
Message-ID: <5513C167.6010601@erikros.me>
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Manu Sporny <msporny@digitalbazaar.com>
CC: W3C Credentials Community Group <public-credentials@w3.org>
Hi everyone,

if this decentralized hash table technology was used, would it still be 
necessary to use DNS?
I think we might want to consider looking into vouching more ..

kind regards,

Erik

On 26-03-15 06:47, Adrian Hope-Bailie wrote:
>
>     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.
>
>
> I have read both blog posts but thanks, it was worth re-reading them :)
>
>     > 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.
>
>
> I am not proposing that we use email addresses but rather "identifiers 
> that follow the same form".
> It's a familiar and sensible format for an identifier.
>
>     -1 to making the IdP the same domain as the email address. Doing that
>     creates a monopoly (Google for gmail.com
>     <http://gmail.com/> addresses, for example).
>
>
> Yes and no.
> As I said in my original email, if users wish to have an identity that 
> is not controlled by their email provider they can get one that is 
> controlled by an IdP they trust or one they control.
>
> I have a problem with excluding the large proportion of people that do 
> own or trust an IdP and would like to adopt this standard but are 
> excluded on the basis that many others don't.
>
> Persona failed because the email providers wouldn't play along but 
> that's because the fallback defined by the protocol depended on a 
> centralised service.
>
> I am still an advocate for a WebFinger-like discovery step as the 
> first step in the process of dereferencing an "email style" identifier 
> to an identity document.
> If the outcome is a 404 because the domain owner doesn't support 
> WebFinger or 403 because the client needs authorisation then fall back 
> to option 2 (maybe Telehash or some other decentralised system like 
> Namecoin) or prompt the user for some credential that gives access to 
> the protected resource.
>
> The reality is that if I have an identifier in a specific namespace it 
> is much easier and more secure to manage that identifier using systems 
> in that domain.
> And many users will choose to do this.
>
> We also need to consider that a standard should also have use case 
> applicability in the enterprise space.
> Enterprises that control their domain should be able to offer their 
> employees the capability of having an identity in their namespace.
>
> As a user I expect to have multiple online identities that I can use 
> in different contexts.
> One may be my personal identity and another may be my company identity.
> My company should have the ability to manage elements of the identity 
> they have issued me therefor the domain system as a mechanism for 
> namespaces identities makes a lot of sense.
>
>
>     -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.
>
>
> I am not advocating that "email style" identifiers are the only option 
> but they should be well supported.
>
> Users have the choice between portability and ease-of-use. A standard 
> shouldn't prescribe that they can only have one.
>
>
>     > 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'd like the discovery process that came out of any standard we put 
> together to allow both.
> I see the identity process as having many steps and what we are 
> figuring out here is just the discovery of the IdP.
> I would be in favour of a standard that prescribed how to de-reference 
> an identifier (in a variety of forms) into a URL that points to an 
> existing resource where the identity information can be found.
> BUT it should ALSO prescribe ways that the resource at that URL can 
> link to further identity information (linked data seems the obvious 
> answer)
> BUT it should ALSO prescribe ways that the resource at that URL can be 
> protected and how the user interactions should work to provide access 
> to that resource (OAuth2 or similar?).
>
>
>     > 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.
>
>
> I think the OpenId Connect Discovery protocol has great potential but 
> both that protocol and WebFinger are incomplete.
> They need to handle the use case where even the discovery process 
> fails without some form of security step (like the hashed password 
> proposal in the Credentials spec) to prevent harvesting identifiers.
>
> An idea:
> Implement a Time-based One Time Password 
> (http://www.wikiwand.com/en/Time-based_One-time_Password_Algorithm) to 
> protect the resource discovered from the identity.
> i.e. WebFinger with TOTP to protect the resources at the well-known URL.
> The protocol is used today for many 2FA systems is, standardised and 
> works well.
>
> A 403 response from the service hosting the identity information (or 
> linked data document directing the client to it) should indicate what 
> authorisation, if any, is required.
> The standard should support a variety of these that support use cases for:
>
>   * Preregistered clients of the IdP
>   * Prompting the user for some secret (as above)
>   * Providing a proof-of-work (if avoiding harvesting of data is all
>     that the IdP wishes to achieve as opposed to identity holder
>     authorisation)
>
>     > So how do we help the user that has an email address @gmail.com
>     <http://gmail.com/>
>     > <http://gmail.com <http://gmail.com/>> or @hotmail.com
>     <http://hotmail.com/> <http://hotmail.com <http://hotmail.com/>>
>     or @yahoo.com <http://yahoo.com/>
>     > <http://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 disagree that this means it's not worth trying again with some changes.
> The back-up option shouldn't be a centralised service but I also don't 
> think a de-centralised DB should be the primary look-up service.
>
>
>     > 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.
>
>
> Why? If it's based purely on the fact that it didn't work before then 
> addressing the reasons why should be enough to make it work the second 
> time.
>
>     > 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 <http://gmail.com/>?
>     What's in it for them? Same
>     question goes for all the major email providers.
>
>
> Because it's a W3C standard not a proprietary one developed by one of 
> their competitors.
> Because a lot of people won't bother to setup an alternate IdP and so 
> Google still benefits from the linkability of the identities they host.
> Because if I get an id somewhere else and Google refuse to support at 
> least linking to it then eventually that might become my new email 
> account and so Google loses me completely.
>
>
>     > 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 <http://gmail.com/> address
>     will do this.
>
>
> So we don't give them the choice?
>
>
>     > 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.
>
>
> So we build a standard on the premise that users are too stupid to 
> understand the difference between an email address and an identity and 
> instead of giving them choice we promote a standard that we know out 
> of the gates some of the largest tech providers will ignore because we 
> have explicitly tried to cut them out?
>
> My point around enterprise use cases applies here too.
> Many people do have multiple email addresses. They are already 
> familiar with the idea of having multiple online identities.
>
> Getting an email address at @gmail.com <http://gmail.com/> may not 
> have been an explicit decision to host anything at the gmail.com 
> <http://gmail.com/> domain but if I register a domain and setup an 
> email account at that domain it is.
> I have made an explicit decision to register a namespace on the 
> internet that I can control, why wouldn't I want all of my identity 
> information to sit under that namespace?
>
>
>     > 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 <http://identus.org/> demo is something you should
>     look at... I'd be happy to go
>     through it w/ you at some point.
>
>
> I have been through the blog-posts and the demo some time ago but I'm 
> afraid I think asking the world to abandon the email style identifier 
> with no bridge from that system to something truly decentralised is 
> doomed.
> I agree that a decentralised system is the end-goal and as time goes 
> by more and more people will begin to own their own domains and be 
> able to control the services that reside on them.
>
> Remember, the email system is already decentralised, the issue you are 
> talking about is the large proportion of people who have got their 
> email addresses form specific providers.
> You have already stated that email addresses change all the time so 
> you can't then argue against a system where users have the choice of a 
> different IdP by... changing their email address.
>
> I have an email address at a domain I own. I plan to use it for my 
> whole life.
> I trust my ability to host my own IdP more than some decentralised 
> system controlled by entities I don't know.
> Is this standard going to force me to enter in some URL when I want to 
> share my identity online or can I just use my email address as I 
> already do today?
>
> I am worried that there is an obsession with decentralisation here 
> ignoring the fact that the Web is decentralised and at the core of 
> that DNS.
> Are we saying that DNS is not decentralised enough for our needs?
> If so why would this standard be developed under the banner of the W3C 
> at all?
>
> On 23 March 2015 at 05:24, Manu Sporny <msporny@digitalbazaar.com 
> <mailto:msporny@digitalbazaar.com>> wrote:
>
>     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 <http://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>
>     > <http://gmail.com> or @hotmail.com <http://hotmail.com>
>     <http://hotmail.com> or @yahoo.com <http://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 <http://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 <http://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 <http://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/
>
>

-- 
=========================
--  Erik Ros           --
--  +447979090626      --
--  mail@erikros.me    --
--  http://erikros.me  --
--  @erikros_me        --
--  +ErikRos_ejfrme    --
=========================
Received on Thursday, 26 March 2015 08:21:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:23 UTC