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