Re: Leveraging DNS and email addresses

This a is a great summary/checkpoint Dave.

My only changes would be:

3. Allow people to use identifiers that aren't controlled by any other
entity
7. Allow people to log into websites using their identifier (and a
password/OTP or 2F device if they choose)
8. Allow people to protect their privacy by obscuring the websites they log
into from their IdPs.


On 27 March 2015 at 16:53, Dave Longley <dlongley@digitalbazaar.com> wrote:

>  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 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> or @hotmail.com <http://hotmail.com> or @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? 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 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 may not have been an explicit
> decision to host anything at the 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 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> 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 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> or @hotmail.com <http://hotmail.com> or @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? 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 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 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
>
>