Re: Leveraging DNS and email addresses

inOctober 2013 i put together some ideas  around datastore functionality,
et.al. http://mediaprophet.org/ux_KB/index.html

the account recovery method made a specific attempt not to use an email
address: http://mediaprophet.org/ux_KB/page4115286.html

another aspect is the work by Oshani (and team)

[1] http://newsoffice.mit.edu/2014/whos-using-your-data-httpa-0613
[2] http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf


Timh.


On 24 March 2015 at 03:22, <Axel.Nennker@telekom.de> wrote:

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