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/
> >
>
>
>
>