Re: Leveraging DNS and email addresses

+1 @all
On Mar 25, 2015 11:16 AM, "Wiley, Glen" <gwiley@verisign.com> wrote:

>  I agree that we need to consider how web clients would use our
> solutions.  There are active discussions about how to integrate this into
> the most common web clients (browsers etc.).  As with any meaningful steps
> forward in technology the various client platforms will adopt the
> technologies that fit best with user experiences and meet the user needs
> that they have identified.
>
>  Using history as a guide many of the technologies that we considered
> “low level” have percolated into the web clients, I expect that this follow
> a similar trajectory.
>  --
> Glen Wiley
>  Principal Engineer
> Verisign, Inc.
> (571) 230-7917
>
>  A5E5 E373 3C75 5B3E 2E24
> 6A0F DC65 2354 9946 C63A
>
>   From: Adrian Hope-Bailie <adrian@hopebailie.com>
> Date: Wednesday, March 25, 2015 at 9:28 AM
> To: Wiley Glen <gwiley@verisign.com>
> Cc: Melvin Carvalho <melvincarvalho@gmail.com>, W3C Credentials Community
> Group <public-credentials@w3.org>
> Subject: Re: Leveraging DNS and email addresses
>
>   Hi Glen,
>
>  I prefer the use of DNS for service discovery over something like
> WebFinger but it presents a problem for Web clients that don't have access
> to such low levels in the stack.
> We need to consider this in whatever is proposed.
>
>  Adrian
>
> On 23 March 2015 at 16:53, Wiley, Glen <gwiley@verisign.com> wrote:
>
>>  Melvin,
>>
>>  Some of your points are correct, email addresses are pretty over loaded
>> however is this really an either-or discussion?  Does offering email
>> addresses as a locator prevent discussion of other mechanisms?  It isn’t
>> clear to me how it stalls other work?
>>
>>  One way to avoid an endless debate is to embrace cooperative approaches
>> rather than insisting on a single approach.
>>
>>  One of the ways I have proposed we leverage payment information
>> associations this way is to offer a secured referral to a URI – you can
>> locate the association in the DNS using an email address which then takes
>> you to a resource record that offers a URI.  This can be accomplished by
>> leveraging the chain of trust within the DNS and by leveraging
>> cryptographic assets to make the handoff to the URI (e.g. A certificate or
>> public key).
>>   --
>> Glen Wiley
>>  Principal Engineer
>> Verisign, Inc.
>> (571) 230-7917
>>
>>  A5E5 E373 3C75 5B3E 2E24
>> 6A0F DC65 2354 9946 C63A
>>
>>   From: Melvin Carvalho <melvincarvalho@gmail.com>
>> Date: Monday, March 23, 2015 at 10:36 AM
>> To: Adrian Hope-Bailie <adrian@hopebailie.com>
>> Cc: W3C Credentials Community Group <public-credentials@w3.org>
>> Subject: Re: Leveraging DNS and email addresses
>> Resent-From: <public-credentials@w3.org>
>> Resent-Date: Monday, March 23, 2015 at 10:37 AM
>>
>>
>>
>> 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
>>>
>>
>>
>