W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Re: Leveraging DNS and email addresses

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 25 Mar 2015 16:28:23 +0200
Message-ID: <CA+eFz_LcaY=hGzjrCPA1dwmZUf603NsTeF55ksPjRnCyHziW1g@mail.gmail.com>
To: "Wiley, Glen" <gwiley@verisign.com>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, W3C Credentials Community Group <public-credentials@w3.org>
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.


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
Received on Wednesday, 25 March 2015 14:28:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:39 UTC