- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 27 Mar 2015 10:53:45 -0400
- To: public-credentials@w3.org
- Message-ID: <55156EF9.7070401@digitalbazaar.com>
I think we should: 1. Allow people to have multiple identities on the Web. 2. Have each identity be canonically identified by a single identifier. 3. Ensure that the identifier isn't controlled by or tied to any particular domain. 4. Allow credentials to be associated with an identifier. 5. Allow people to associate their identifier with an IdP to provide management of their credentials. 6. Allow people to change which IdP they have associated with their identifier at any time. 7. Allow people to log into websites using their email address (and a password/2F device). 8. Protect people's privacy by obscuring the websites they log into from their IdPs. 9. Allow people to use credentials to gain privileges to take actions or to get access to services. 10. Allow issuers of credentials to make whatever domain-specific claims they want to about an identity. 11. Ensure the authenticity of claims made in credentials can be verified. In order to accomplish these goals, I think we should create technology that: 1. Allows people to freely claim unclaimed identifiers and that prevents claiming already-claimed identifiers. 2. Can resolve memorable information, such as an email address (and possibly a password), to an identifier. 3. Allows people to provide credentials to websites and to receive new credentials in a standard way. 4. Allows websites to request credentials from people where the person need only enter an email address and password to be redirected to their IdP of choice to be shown the request. The email address and password are not sent to the website that requests the credentials. 5. Implements login as the request and verification of a credential. 6. Allows people to permit services to non-interactively obtain their credentials (eg: authenticated REST API). 7. Uses Linked Data to specify claims in credentials. 8. Uses a PKI to ensure the authenticity of claims made in credentials. There are more details to implementing all of these technologies, but I do think that the Identity Credentials spec and the identus.org demo cover most of these concepts. We just need to do a better job of communicating that -- or improving where we fall short. -Dave On 03/26/2015 02:47 AM, 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/ > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Friday, 27 March 2015 14:54:13 UTC