Re: Leveraging DNS and email addresses

On 23 March 2015 at 16:11, Wiley, Glen <gwiley@verisign.com> wrote:

>   Think of an email address as one of many possible locators.  I agree
> that it may not solve all the cases but it offers one of the most well
> recognized “handles” to the less technical segments of our population.
> Even the non-tech savy internet users understand how to exchange email
> addresses.
>

+1


>  It may be that email serves an adoption boost that gives people a bridge
> to better locators.
>

+1 this would be the ideal


>  --
> Glen Wiley
>  Principal Engineer
> Verisign, Inc.
> (571) 230-7917
>
>  A5E5 E373 3C75 5B3E 2E24
> 6A0F DC65 2354 9946 C63A
>
>   From: Eric Korb <eric.korb@accreditrust.com>
> Date: Monday, March 23, 2015 at 9:51 AM
> To: Wiley Glen <gwiley@verisign.com>
> Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <
> public-credentials@w3.org>
> Subject: Re: Leveraging DNS and email addresses
>
>   I'm not in love with the idea of using email as a keying mechanism,
> except I do agree it is something people do remember.
>
>  However, I think an important to point out that an "entity" can be a
> person, place or thing.  Yes, a place and thing can be assigned an email
> address.  But, we need to keep in mind that that first-proof of ownership
> of an identity credential does need to be validated and signed by some
> authority, which is likely the IdP. Therefore, the method of using an
> email keying mechanism for place or thing needs to be thought through
> between an IdP and an entity of type place or thing.
>
>  I also agree that we need to consider that a person may have multiple
> emails for various reasons, be it business, personal, educational, etc.
> So, being able to change the associated email address with your IdP is a
> use case we need to consider.
>
>  Eric
>
>
>  *"Trust only credentials that are TrueCred*™ *verified."*
>  ----------------------------------
>  Eric Korb, President/CEO - accreditrust.com
> <https://www.accreditrust.com>
> GoogleVoice: 908-248-4252
> http://www.linkedin.com/in/erickorb @erickorb @accreditrust
>
> On Mon, Mar 23, 2015 at 12:09 AM, Wiley, Glen <gwiley@verisign.com> wrote:
>
>> There are some active discussions in the DNS community about how to handle
>> this and Verisign has put together some proof of concept code to allow
>> folks to experiment with it.  The substrate leverages DNSSEC and DANE to
>> ensure reliably secure delivery.  The problem of how to address key
>> material for users who do not have privileges to modify a zone is the real
>> problem.
>>
>> One of the proposals I have made in the DNS circles (speaking on it at
>> IETF92 this week in Dallas) is to provide more effective authorizations to
>> users within zones.
>>
>> One of the reasons people leveraging email providers (like gmail) would
>> want this is that they still want a way to sign and encrypt their
>> communications.  While many of us who are more security aware balk at the
>> idea, it isn¹t a question of ³best², rather it is a question of ³good
>> enough² for mass adoption.  A few of us at Verisign are working through
>> ideas about how to solve this for the large email services in an open and
>> interoperable way that is simple enough to be adopted by non-technical
>> users but still offers a reasonable degree of security.
>> --
>> Glen Wiley
>>
>> Principal Engineer
>> Verisign, Inc.
>> (571) 230-7917
>>
>> A5E5 E373 3C75 5B3E 2E24
>> 6A0F DC65 2354 9946 C63A
>>
>>
>>
>>
>> On 3/22/15, 11:24 PM, "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/
>> >
>>
>>
>>
>>
>