- From: Erik Ros <mail@erikros.me>
- Date: Thu, 26 Mar 2015 15:11:19 +0000
- To: "Wiley, Glen" <gwiley@verisign.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Manu Sporny <msporny@digitalbazaar.com>
- CC: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <55142197.60209@erikros.me>
A carpenter I see.. I'm from the Netherlands, and the very strongly protected trust anchor is, I'm afraid, no longer a reality there: http://en.wikipedia.org/wiki/DigiNotar I was thinking about how people get to trust other people. In real life this often is done through vouching: Meet my friend, she's a good person (as is done on social media).. On the internet we have formal vouching agencies. Couldn't we make some kind of decentralized system for vouching, with a special roll for vouching agencies.. layered vouching: Adrian suggest something like that in a way when talking about identifying (see the other active thread) maybe that requires to much user involvement? I don't know.. I was thinking about this approach to DNS too. When my friends talk about coke, it won't mean we talk about the same thing as others do (just so we are clear, we only refer to coke as the black beverage). I think DNS should work in this way to. Then with the right amount of linked data evidence and some risk assessment statistics, one could resolve safely. Domain trolls would lose all respect and nobody would vouch for them. (I am realizing I'm perhaps being to creative / fantastic right now) with regards Erik On 26-03-15 14:10, Wiley, Glen wrote: > Since DNS is my particular favorite hammer I am biased toward seeing > everything as a nail shaped to fit it :) > > The answer to your question lies in what we need in the infrastructure > and how we can best address those needs. In my mind the most > important thing that DNS (via DNSSEC and DANE) brings to the table is > a currently implemented infrastructure that delivers a very strongly > protected trust anchor AND a robust, cryptographically strong chain of > trust with the means for terminal points in that chain of trust to > safely manage their cryptological assets. > > I think the right way to answer your question is to do our best to > combine what we understand we need in the infrastructure with pieces > of infrastructure that get us as close as possible to meeting those > needs with the least effort. > > -- > Glen Wiley > Principal Engineer > Verisign, Inc. > (571) 230-7917 > > A5E5 E373 3C75 5B3E 2E24 > 6A0F DC65 2354 9946 C63A > > From: Erik Ros <mail@erikros.me <mailto:mail@erikros.me>> > Date: Thursday, March 26, 2015 at 3:20 AM > To: Adrian Hope-Bailie <adrian@hopebailie.com > <mailto:adrian@hopebailie.com>>, Manu Sporny > <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> > Cc: W3C Credentials Community Group <public-credentials@w3.org > <mailto:public-credentials@w3.org>> > Subject: Re: Leveraging DNS and email addresses > Resent-From: <public-credentials@w3.org > <mailto:public-credentials@w3.org>> > Resent-Date: Thursday, March 26, 2015 at 3:21 AM > > 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 -- > ========================= -- ========================= -- Erik Ros -- -- +447979090626 -- -- mail@erikros.me -- -- http://erikros.me -- -- @erikros_me -- -- +ErikRos_ejfrme -- =========================
Received on Thursday, 26 March 2015 15:11:59 UTC