RE: Leveraging DNS and email addresses

I would like to add privacy and unlinkability to the discussion.


-          Emails and other identifiers like e.g. phone numbers are linkable
Temporary email approaches failed in the past.

-          Email-like identifiers need not be usable email-addresses: randomid@idp.com<mailto:randomid@idp.com>

-          The discussion to use email addresses as openids goes back years.
People remember email addresses but don’t know about linkability.

-          The openid accountchooser WG uses emails but the relying party is the ultimate acceptance point and decides which IdPs are “good”.
Therefore IdP Icons were chosen compromise
http://www.accountchooser.net/developers


-          Users fear getting spam when they have to give email/phone# to website

-          Tokenization moves from PANs to tokens which is good for privacy

My fear is that we are selling technologies (again) as in: solution looking for a problem.

In the end website owners are the most important players regarding success or failure of “credentials”.


From: Timothy Holborn [mailto:timothy.holborn@gmail.com]
Sent: Monday, March 23, 2015 4:37 PM
To: Wiley, Glen
Cc: Melvin Carvalho; Adrian Hope-Bailie; W3C Credentials Community Group
Subject: Re: Leveraging DNS and email addresses

conversation does seem complex...  few thoughts in the general vicinity...

1. mailto:

Email has been used as a security mechanism; sometimes making a persons account only as secure as the barriers of access to their email service.  2-factor does improve things.

I don't think that's the issue here; yet, it's still jumbled up with the email issue if we're using mailto:

I also consider that email-addresses are not subject to KYC/AML and whilst someone may in-turn perform those types of functions with their Credential Service (ie: using banking auth, or passport, mobile, etc.); we don't necessarily know whether their sending mail to their own address or someone else's.  I have an array of related considerations pertaining to the many days i've spent in my life fixing computers for people; whether the device owner is in the same room or in a different country...

notably; the issues in setting-up systems for politically exposed people - was interesting, paypal doesn't like it...  it was easier to give them access to my paypal account...

so, underlying the use of mailto: is the question - did someone else help them set-up their credentialing service, and point the account at their own email - to make it easier for the vulnerable.

2. Accessibility
Accessibility is also important; including use-cases such as deceased or incapacitated people.

3. Portability
Yet another consideration - the identifier debate reminds me of the portability issue that was spoken about by sandro hawke [1] - where the concept of subdomains and redirection policies were discussed as a means of supporting portability...

I also imagine that a mobile phone number might be as easy to remember as an email address...  perhaps in-turn that denotes the concept of a telco's credentialing service, enabling a mobile phone number to become a HTTP URI?

(yet, if i change my simcard/phone-number i don't necessarily get a phone-number redirection service.  this is either not supported, or conditionally supported function as far as i'm aware...)

4. Social-Network URI's
Facebook has URI's [2] as do most other similar services. they've also got messaging systems built into them.

5. mobile internet device usage
Mobile usage is quite significant from memory...  What devices are we targeting for the 'easy to use' high-accessibility option?

The specifics don't come to mind, but do regions exist where it's easier to get a mobile with internet access, than a bank-account?  does this apply to travellers also?

[1] https://www.youtube.com/watch?v=AzMmVr2VUFU&t=1930

[2] https://graph.facebook.com/timothy.holborn


On 24 March 2015 at 01:53, Wiley, Glen <gwiley@verisign.com<mailto: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<mailto:melvincarvalho@gmail.com>>
Date: Monday, March 23, 2015 at 10:36 AM
To: Adrian Hope-Bailie <adrian@hopebailie.com<mailto:adrian@hopebailie.com>>
Cc: W3C Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Leveraging DNS and email addresses
Resent-From: <public-credentials@w3.org<mailto: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<mailto: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<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?

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