- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 27 Mar 2015 12:10:50 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <5515810A.3010905@digitalbazaar.com>
On 03/27/2015 11:37 AM, Melvin Carvalho wrote: > > > On 27 March 2015 at 15:53, Dave Longley <dlongley@digitalbazaar.com > <mailto:dlongley@digitalbazaar.com>> wrote: > > I think we should: > > > +0 controlled yes, tied to is inevitable, at least with http: and mailto: +1, By "tied to" I meant bound in a way that cannot be changed. There would certainly be a link at some point. > > 8. Protect people's privacy by obscuring the websites they log > into from their IdPs. > > > +0 id rather use the term "Allow" here +1 > > 11. Ensure the authenticity of claims made in credentials can be > verified. > > > -1 sometimes claims are in a state pending verification for example To clarify, I meant that you can check that the claims (whatever they may be) were made by a particular entity (digital signatures); I wasn't referring to the veracity of the claims themselves. > > 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 <http://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. > > > +1, I think UI details should be out of scope of the core, and limited > to case studies. Each implementer can implement the UI as they > prefer, and no one should impose their UI implementation details or > workflow on another. +1 to keeping UI details out of scope. > > -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 > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Friday, 27 March 2015 16:11:14 UTC