Re: Leveraging DNS and email addresses

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)".
(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
>>
>
>