The only difference is that Google doesn't provide identity verification, only identity validation when you have previous knowledge of a Google account being associated to a user account.
> Third-party identity providers enable you to rely on a trusted external service to authenticate a user's identity. Google, Facebook and Twitter are commonly used providers
The highly trusted Google and Facebook indeed. Nothing like a fresh oxymoron to start my Sunday.
> moving the job of identity verification into OpenID identity providers
Please, don't. This idea is horrible.
With OpenID (and xAuth and Persona and whatever) your identity is provided, not asserted. This is very important distinction. I believe, any sane person wants to be a source of their identity (that's asserted by others), not to lease their very identity from a third party.
If you want an identity - generate a keypair. Publish your public key and let others sign it to assert this keypair is genuinely yours. It's that easy. (Although, sadly, X.509 doesn't support multiple signatures, so one can't do a proper web-of-trust with them.)
If you want automated domain ownership verification and completely automated certificate signing (and whois-pointed email ownership check is not to your taste) - well, how about putting a CSR right in TXT record of the domain? CA-bot would see those and sign them. No need for identity providers except for a domain registrar.
> I hope it doesn't become the default for most sites (which have no need for your actual identity) but for many use cases I can see the need for varying levels of identity tied to your real identity
Varying levels is probably the right approach.
For most sites all they need to know when I create an account is that I control the email address that I am using to sign up. If I ever again need to prove my identity to them proving that I receive email at that address is good enough.
For the site that provides my email address they need something other than email to identify me.
If I'm using an email provider that lets you bring your own domain, they could use proof that I control the DNS for that domain as proof of identity.
How to prove identity to my domain registrar? I could use an email address that is not hosted somewhere that depends on my proof of domain ownership, like gmail or my ISP, but that is probably not a good idea. Ultimately, my ability to prove my identity at most sites would depend on proving identity to my domain registrar (or to my email host if I don't have my own domain), and so making that depend on remaining in good standing with Google might not be wise.
What we need for proving identity to a domain register (or an email provider if you don't have your own domain) is something that we can be sure we can rely on, because in the worst case when you've been massively hacked and your identity has been stolen at multiple sites and services that is going to be the identity proof you count on to let you recover everything else.
For that something like the USPS identity service would be great.
It's not. You seem to have misread the article. moot's saying that it's important "who you share as" not "who you share with". G+ doesn't allow you to have multiple identities, it allows you to share in different contexts with the same identity - which is fundamentally different.
Besides, it's a very bad idea to leave identity management in the hands of a third party anyways, and the last third party I'd trust with my identities are Google and Facebook. Call me paranoid all you want, but identities are something you manage yourself - nobody should be trusted doing it for you.
What's the point of a an identity provider if it doesn't authenticate the user? Yes, maybe it's valid according to the spec, but that's not what it's designed for. No need to confuse people on theoretical data differences that don't appear in practice.
"But that solution is quite complex hindering its adoption."
Generally inventions solve problems by making them simpler, for this to be a valuable invention it would need to be simpler and less hackable to use than log-in with google/FB/github. I can still recover my google account if I forget my password, and don't have a reset setup. What aspect of distributed identity/ self-sovereing identity do customers care about? how does blockchain simplify this for them?
> You already have that without requiring any buzzword-driven marketingspeak.
> And if your goal is to stay anonymous, in the very least you'd be using independent dedicated identities in separate services.
It is free to create a new identity on EVM. You just create a new public-private key pair. You can do it right now, in the browser, on the fly. If you want to have different accounts for different platforms (or multiple accounts for the same platform), you would have that ability (that is the case today, in Web3). But, if you want to integrate across platforms, it is far easier if those applications adopt an open, user-owned identity standard (rather than rely on Google or Gmail or Facebook or hotmail).
As far as I can tell, you're relying on Google, or Microsoft, etc to verify your identity. Lose your relationship with them, and you lose control of everything. You have to remain in their good graces, or lose your identity for a diverse set of transactions where those big players would otherwise have no sway.
Would much rather have a truly decentralized identity where you can change providers without losing continuity of your identity. Where your identity provider has to keep you happy, or you transparently move your identity to a new provider.
I'd commented to the same effect earlier on Google's own Identity Service: Google+.
I think Google's dropped the ball, badly, on identity and authentication (though they're ... making some movement with physical 2FA).
I've got massive misgivings myself about private tech firms getting into this space, though I do think they might have useful elements to add by way of suggesting protocols and standards. And I'd be really suprised if various majors aren't part of the discussion. Google, Facebook, Microsoft (remember Passport?), Oracle, IBM. And databrokers such as ADP. Plus banking and financial institutions, who've mostly created the mess....
> Well, the solutions offered then have failed, but did they systematically rule out all possible technologies and business models?
Of course not. In fact, business models were only considered tangentially in most cases because the general goal was to create an ecosystem of federated identity providers transacting over open protocols. Differentiation would come from the relationship between customers and their providers - charging for background checks to add extra confidence to third-party claims, for example. Or, by selling enterprises more secure identity claim brokers for their employees.
> One problem is username and password proliferation. Another is filling out the same information over and over, like phone number, email address, and so on. E-commerce sites will often not bother checking email addresses and not require accounts because unnecessary obstacles drive potential customers away.
I'd love to see the Digital Identity discussion revived, and between high-profile security breaches (Adobe, Target...) and the NSA, I think it might be time.
I know you don't have or necessarily want a preconceived idea of what a 3rd-party account/identity provider should be, but I encourage you to look at what's been done & discussed before.
Dick Hardt's keynote from the 2006 Identity 2.0 conference is entertaining and informative: https://www.youtube.com/watch?v=RrpajcAgR1E - it's also the talk that got me hooked on Vanilla Stoli for a couple of years.
Kim Cameron's "Laws of Identity" were the cornerstone of the discussion back them. They outline a system of federation, user control & consent, and minimal disclosure. Cameron's site also has lot of information about CardSpace/InfoCards (the open standard) and his blog covers some more modern Identity systems from Microsoft: http://www.identityblog.com/stories/2004/12/09/thelaws.html
I guess it would also be good to look at tools like 1Password which can fill out registration forms and passwords already, and see why they haven't been adopted more widely.
I'm all for that, but realistically how will you verify identity? If there is no identity verification what is stopping me from going out and registering for "google.com" and then using it in my MITM attack?
Thanks Terretta! Dom, Co-founder at Uify here. I fully agree that the available ecosystem of identity providers is diverse, and that the user should not be limited to a single one, or a small subset. We have multiple authentication methods on our roadmap, and hope we can release those in the near future.
Third-party identity providers are bad for a number of reasons. My biggest issue is that none of the mentioned services make any guarantees against arbitrary account termination or lockdown. If the identity provider decides to lock you out, there's no recourse for the user. Google Accounts are notorious for this, making it nigh impossible to reach a human unless you have an engineering connection on the inside.
This post is a blatant ad for Firebase Auth. Why isn't there any mention of competing services like Auth0 and okta?
There's also lots of frameworks and libraries which handle everything for you with minimal effort. For example, you could setup something like Apache Shiro [0] as an independent service which you call out to from your app. I've seen a few different alternatives in this space, although I can't remember their names off the top of my head. They're usually written in Java, presumably because getting these features right is important for some enterprises.
I think we already have that: Google ;)
The only difference is that Google doesn't provide identity verification, only identity validation when you have previous knowledge of a Google account being associated to a user account.
reply