Re: Leveraging DNS and email addresses

+1 @all love this discussion
On Mar 27, 2015 12:11 PM, "Dave Longley" <dlongley@digitalbazaar.com> wrote:

>  On 03/27/2015 11:37 AM, Melvin Carvalho wrote:
>
>
>
> On 27 March 2015 at 15:53, Dave Longley <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 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 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
>>
>>
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.http://digitalbazaar.com
>
>