Re: Leveraging DNS and email addresses

Found http://www.certificate-transparency.org/ today - searching googles
github: https://github.com/google/certificate-transparency

Vint once gave me the advice that 'IPv6 is a topological identifier and
should NOT be used as a logical one.'

Melvin spent quite a bit of time going through [#axioms] with me. Had a
rather extensive debate about the use of the term 'agent' in [#FOAF]

[#cooluris]  seems to summarise some of the underlying concepts...

hopefully some helpful fragments... let me know if i'm off target...

TimH.

[#FOAF] http://xmlns.com/foaf/spec/
[#cooluris] http://www.w3.org/TR/cooluris/
[#axioms] http://www.w3.org/DesignIssues/Axioms.html

On 23 March 2015 at 14:24, 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/
>
>