Re: Leveraging DNS and email addresses

On 25 March 2015 at 15:26, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> Take a moment to consider the user experience.
> I am a person that wishes to register on a website and the website prompts
> me for my online identity (or some cool name we give this thing eventually
> and spend millions marketing it).
>
> I am presented with a text box labelled "Online Identity" (or similar) and
> optionally another labelled "One Time Pin (optional)".
>

You dont need to only use a textbox as an input mechanism.

For example, the browser has an address bar to input http uris, but most
uris are not typed, they are clicked on via links and buttons.


> (The OTP is a time-based OTP - see my response to Manu).
>
> I enter my identity (an email address looking thing, a URL, a mobile
> number, etc) and click "Register"
> At this point the Credentials spec should tell the client how to use that
> value to discover my IdP and through a combination of linked data documents
> and possibly user prompts or redirects gather my identity data as required
> and allowed.
>
> If I enter an email address (email@something.com) and the website says
> "Sorry, only URL's are allowed." because I was supposed to enter it as
> "mailto:email@something.com" I consider our efforts to have failed.
>
> Longer term we'd want the browser to do a lot of work in the background,
> use stored identities and prompt the user which ones to use.
>
>
> On 23 March 2015 at 16:36, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 16 March 2015 at 09:02, Adrian Hope-Bailie <adrian@hopebailie.com>
>> 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
>>>
>>> *ASIDE: It's worth mentioning that while we strive for a fully
>>> decentralised identity system this will likely be a federated set of IdPs
>>> and for a client to traverse this web they need a starting point or primary
>>> IdP for an identity. When I talk about the IdP for an identity I am not
>>> implying there will be only 1 but that that the key/label for the identity
>>> should allow a client to resolve/discover this primary IdP and then from
>>> there discover further identity claims as required.*
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> So how do we help the user that has an email address @gmail.com or @
>>> hotmail.com or @yahoo.com but wishes to host their identity themselves
>>> or at a different IdP?
>>>
>>> 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.
>>>
>>> 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 prpvode 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.
>>>
>>> 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.
>>>
>>> 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
>>>    2. Use an identity that is different from their primary email
>>>    address.
>>>
>>>
>>> Option 2 can be easily facilitated by any IdP who wishes to play in this
>>> space. In conjunction with offering an IdP service they could also allow
>>> their identity key (email address) to be used as an email address by the
>>> subscriber but simply forward all emails to that address on to the primary
>>> email address of the subscriber.
>>>
>>> I think the Discovery protocol of OpenID Connect (
>>> http://openid.net/specs/openid-connect-discovery-1_0.html) is a good
>>> reference of how an email address could be used to discover the user's IdP
>>> however I'd be more in favour of leveraging the DNS service discovery
>>> protocol (RFC 6763 - http://www.dns-sd.org/).
>>>
>>> Is there a compelling case for using a URI as an identity key as opposed
>>> to the familar form of an email address?
>>>
>>
>> Let's not go down this path in discussion.  Email is confusing because
>> it's overloaded to do different things:
>>
>> 1. A memorable identifier
>> 2. A global primary key
>> 3. A message delivery service
>>
>> This stalls meaningful discussion in the standards world, and we end up
>> with failed projects such as persona.
>>
>> Just using web axioms an email address as an identifier (2) is already a
>> URI by prefixing mailto: (something that most centralized and many
>> 'decentralized' systems forget to do)
>>
>> In the linked data world we prefer http uris.
>>
>> This is an endless perma debate that gets in the way of standards.  Let's
>> not go there!
>>
>>
>>>
>>> Adrian
>>>
>>
>>
>