Re: Leveraging DNS and email addresses

+1 for passcode
On Mar 29, 2015 11:08 AM, "Timothy Holborn" <timothy.holborn@gmail.com>
wrote:

> Can we use the term "passcode" rather than "password"...
>
> Good secrets in this area 420!$+MaYBeUsIng~mixtures/NotAword
> On 28/03/2015 6:13 pm, "Adrian Hope-Bailie" <adrian@hopebailie.com> wrote:
>
>> 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
>>>
>>>
>>