W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Re: Leveraging DNS and email addresses

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Fri, 27 Mar 2015 12:10:50 -0400
Message-ID: <5515810A.3010905@digitalbazaar.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: W3C Credentials Community Group <public-credentials@w3.org>
On 03/27/2015 11:37 AM, Melvin Carvalho wrote:
>
>
> On 27 March 2015 at 15:53, Dave Longley <dlongley@digitalbazaar.com 
> <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     I think we should:
>
>
> +0 controlled yes, tied to is inevitable, at least with http: and mailto:

+1, By "tied to" I meant bound in a way that cannot be changed. There 
would certainly be a link at some point.

>
>     8. Protect people's privacy by obscuring the websites they log
>     into from their IdPs.
>
>
> +0 id rather use the term "Allow" here

+1

>
>     11. Ensure the authenticity of claims made in credentials can be
>     verified.
>
>
> -1 sometimes claims are in a state pending verification for example

To clarify, I meant that you can check that the claims (whatever they 
may be) were made by a particular entity (digital signatures); I wasn't 
referring to the veracity of the claims themselves.

>
>     In order to accomplish these goals, I think we should create
>     technology that:
>
>     1. Allows people to freely claim unclaimed identifiers and that
>     prevents claiming already-claimed identifiers.
>     2. Can resolve memorable information, such as an email address
>     (and possibly a password), to an identifier.
>     3. Allows people to provide credentials to websites and to receive
>     new credentials in a standard way.
>     4. Allows websites to request credentials from people where the
>     person need only enter an email address and password to be
>     redirected to their IdP of choice to be shown the request. The
>     email address and password are not sent to the website that
>     requests the credentials.
>     5. Implements login as the request and verification of a credential.
>     6. Allows people to permit services to non-interactively obtain
>     their credentials (eg: authenticated REST API).
>     7. Uses Linked Data to specify claims in credentials.
>     8. Uses a PKI to ensure the authenticity of claims made in
>     credentials.
>
>     There are more details to implementing all of these technologies,
>     but I do think that the Identity Credentials spec and the
>     identus.org <http://identus.org> demo cover most of these
>     concepts. We just need to do a better job of communicating that --
>     or improving where we fall short.
>
>
> +1, I think UI details should be out of scope of the core, and limited 
> to case studies.  Each implementer can implement the UI as they 
> prefer, and no one should impose their UI implementation details or 
> workflow on another.

+1 to keeping UI details out of scope.

>
>     -Dave
>
>
>
>     On 03/26/2015 02:47 AM, Adrian Hope-Bailie 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.
>>
>>
>>     I have read both blog posts but thanks, it was worth re-reading
>>     them :)
>>
>>         > 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.
>>
>>
>>     I am not proposing that we use email addresses but rather
>>     "identifiers that follow the same form".
>>     It's a familiar and sensible format for an identifier.
>>
>>         -1 to making the IdP the same domain as the email address.
>>         Doing that
>>         creates a monopoly (Google for gmail.com
>>         <http://gmail.com/> addresses, for example).
>>
>>
>>     Yes and no.
>>     As I said in my original email, if users wish to have an identity
>>     that is not controlled by their email provider they can get one
>>     that is controlled by an IdP they trust or one they control.
>>
>>     I have a problem with excluding the large proportion of people
>>     that do own or trust an IdP and would like to adopt this standard
>>     but are excluded on the basis that many others don't.
>>
>>     Persona failed because the email providers wouldn't play along
>>     but that's because the fallback defined by the protocol depended
>>     on a centralised service.
>>
>>     I am still an advocate for a WebFinger-like discovery step as the
>>     first step in the process of dereferencing an "email style"
>>     identifier to an identity document.
>>     If the outcome is a 404 because the domain owner doesn't support
>>     WebFinger or 403 because the client needs authorisation then fall
>>     back to option 2 (maybe Telehash or some other decentralised
>>     system like Namecoin) or prompt the user for some credential that
>>     gives access to the protected resource.
>>
>>     The reality is that if I have an identifier in a specific
>>     namespace it is much easier and more secure to manage that
>>     identifier using systems in that domain.
>>     And many users will choose to do this.
>>
>>     We also need to consider that a standard should also have use
>>     case applicability in the enterprise space.
>>     Enterprises that control their domain should be able to offer
>>     their employees the capability of having an identity in their
>>     namespace.
>>
>>     As a user I expect to have multiple online identities that I can
>>     use in different contexts.
>>     One may be my personal identity and another may be my company
>>     identity.
>>     My company should have the ability to manage elements of the
>>     identity they have issued me therefor the domain system as a
>>     mechanism for namespaces identities makes a lot of sense.
>>
>>
>>         -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.
>>
>>
>>     I am not advocating that "email style" identifiers are the only
>>     option but they should be well supported.
>>
>>     Users have the choice between portability and ease-of-use. A
>>     standard shouldn't prescribe that they can only have one.
>>
>>
>>         > 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'd like the discovery process that came out of any standard we
>>     put together to allow both.
>>     I see the identity process as having many steps and what we are
>>     figuring out here is just the discovery of the IdP.
>>     I would be in favour of a standard that prescribed how to
>>     de-reference an identifier (in a variety of forms) into a URL
>>     that points to an existing resource where the identity
>>     information can be found.
>>     BUT it should ALSO prescribe ways that the resource at that URL
>>     can link to further identity information (linked data seems the
>>     obvious answer)
>>     BUT it should ALSO prescribe ways that the resource at that URL
>>     can be protected and how the user interactions should work to
>>     provide access to that resource (OAuth2 or similar?).
>>
>>
>>         > 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.
>>
>>
>>     I think the OpenId Connect Discovery protocol has great potential
>>     but both that protocol and WebFinger are incomplete.
>>     They need to handle the use case where even the discovery process
>>     fails without some form of security step (like the hashed
>>     password proposal in the Credentials spec) to prevent harvesting
>>     identifiers.
>>
>>     An idea:
>>     Implement a Time-based One Time Password
>>     (http://www.wikiwand.com/en/Time-based_One-time_Password_Algorithm)
>>     to protect the resource discovered from the identity.
>>     i.e. WebFinger with TOTP to protect the resources at the
>>     well-known URL.
>>     The protocol is used today for many 2FA systems is, standardised
>>     and works well.
>>
>>     A 403 response from the service hosting the identity information
>>     (or linked data document directing the client to it) should
>>     indicate what authorisation, if any, is required.
>>     The standard should support a variety of these that support use
>>     cases for:
>>
>>       * Preregistered clients of the IdP
>>       * Prompting the user for some secret (as above)
>>       * Providing a proof-of-work (if avoiding harvesting of data is
>>         all that the IdP wishes to achieve as opposed to identity
>>         holder authorisation)
>>
>>         > So how do we help the user that has an email address @gmail.com
>>         <http://gmail.com/>
>>         > <http://gmail.com <http://gmail.com/>> or @hotmail.com
>>         <http://hotmail.com/> <http://hotmail.com
>>         <http://hotmail.com/>> or @yahoo.com <http://yahoo.com/>
>>         > <http://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 disagree that this means it's not worth trying again with some
>>     changes.
>>     The back-up option shouldn't be a centralised service but I also
>>     don't think a de-centralised DB should be the primary look-up
>>     service.
>>
>>
>>         > 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.
>>
>>
>>     Why? If it's based purely on the fact that it didn't work before
>>     then addressing the reasons why should be enough to make it work
>>     the second time.
>>
>>         > 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
>>         <http://gmail.com/>? What's in it for them? Same
>>         question goes for all the major email providers.
>>
>>
>>     Because it's a W3C standard not a proprietary one developed by
>>     one of their competitors.
>>     Because a lot of people won't bother to setup an alternate IdP
>>     and so Google still benefits from the linkability of the
>>     identities they host.
>>     Because if I get an id somewhere else and Google refuse to
>>     support at least linking to it then eventually that might become
>>     my new email account and so Google loses me completely.
>>
>>
>>         > 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
>>         <http://gmail.com/> address will do this.
>>
>>
>>     So we don't give them the choice?
>>
>>
>>         > 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.
>>
>>
>>     So we build a standard on the premise that users are too stupid
>>     to understand the difference between an email address and an
>>     identity and instead of giving them choice we promote a standard
>>     that we know out of the gates some of the largest tech providers
>>     will ignore because we have explicitly tried to cut them out?
>>
>>     My point around enterprise use cases applies here too.
>>     Many people do have multiple email addresses. They are already
>>     familiar with the idea of having multiple online identities.
>>
>>     Getting an email address at @gmail.com <http://gmail.com/> may
>>     not have been an explicit decision to host anything at the
>>     gmail.com <http://gmail.com/> domain but if I register a domain
>>     and setup an email account at that domain it is.
>>     I have made an explicit decision to register a namespace on the
>>     internet that I can control, why wouldn't I want all of my
>>     identity information to sit under that namespace?
>>
>>
>>         > 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 <http://identus.org/> demo is something you
>>         should look at... I'd be happy to go
>>         through it w/ you at some point.
>>
>>
>>     I have been through the blog-posts and the demo some time ago but
>>     I'm afraid I think asking the world to abandon the email style
>>     identifier with no bridge from that system to something truly
>>     decentralised is doomed.
>>     I agree that a decentralised system is the end-goal and as time
>>     goes by more and more people will begin to own their own domains
>>     and be able to control the services that reside on them.
>>
>>     Remember, the email system is already decentralised, the issue
>>     you are talking about is the large proportion of people who have
>>     got their email addresses form specific providers.
>>     You have already stated that email addresses change all the time
>>     so you can't then argue against a system where users have the
>>     choice of a different IdP by... changing their email address.
>>
>>     I have an email address at a domain I own. I plan to use it for
>>     my whole life.
>>     I trust my ability to host my own IdP more than some
>>     decentralised system controlled by entities I don't know.
>>     Is this standard going to force me to enter in some URL when I
>>     want to share my identity online or can I just use my email
>>     address as I already do today?
>>
>>     I am worried that there is an obsession with decentralisation
>>     here ignoring the fact that the Web is decentralised and at the
>>     core of that DNS.
>>     Are we saying that DNS is not decentralised enough for our needs?
>>     If so why would this standard be developed under the banner of
>>     the W3C at all?
>>
>>     On 23 March 2015 at 05:24, Manu Sporny <msporny@digitalbazaar.com
>>     <mailto: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 <http://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>
>>         > <http://gmail.com> or @hotmail.com <http://hotmail.com>
>>         <http://hotmail.com> or @yahoo.com <http://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 <http://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 <http://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 <http://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/
>>
>>
>
>
>     -- 
>     Dave Longley
>     CTO
>     Digital Bazaar, Inc.
>     http://digitalbazaar.com
>
>


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com
Received on Friday, 27 March 2015 16:11:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:23 UTC