Identity Is Dead
constellationr.com
constellationr.com
It's currently heavily focused towards The Netherlands, where citizens can obtain attributes from the Dutch civil registry, such as name, home address and age. These attributes can then be selectively disclosed directly to a relying party, without the identity provider being able to see the transaction [4]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying.
It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated.
[1] https://itunes.apple.com/gb/app/irma-authenticatie/id1294092... or https://play.google.com/store/apps/details?id=org.irmacard.c...
[2] https://github.com/privacybydesign
[3] https://privacybydesign.foundation/publications/
[4] https://privacybydesign.foundation/meeting-slides/slides-8-3...
The fact that the government is involved in this is utterly amazing to me. Are you aware of the conditions which brought about this situation in The Netherlands? I'm wondering why other governments are not following this example, given the issues we've seen with identifiers like Social Security in the US.
Never mind that "states rights" only seems to be about focusing power in the hands of local elites instead of national elites. That might sound like a good thing, until you realize that every nutjob that owns a car dealership can basically become a feudal lord.
"States rights" is about lowering the cost of corruption to something that your stupid neighbor can afford...mind you that it only exists constitutionally so that your stupid neighbor could own slaves.
For example, to avoid the potential tyranny of national ID, we have 50 different administrations of ID with Federally mandated consistent standards, plus US Passports/Passport Cards/Frequent traveller cards, plus completely unregulated schemes for managing identity by multiple private sector companies.
Before DigiD, the Netherlands has had a central digital population register since 1994 called the Gemeentelijke Basisadministratie Persoonsgegevens, but before that analogue version of a population register was in use for quite some time as well.
[1]: https://www.digid.nl/en/about-digid/ [2]: https://www.government.nl/topics/personal-data/citizen-servi...
I'm not kidding.
Nothing would make more sense at this point then some kind of federal identity standard that used real crypto to prove someone's identity. The US Postal Service already has offices in every community that could be used for enrollment. For what it's worth, the Federal Government does this for all it's employees.
In Poland if you want anything from your government online you need to prove who you are. Easiest way to do that is to get redirected from government website to your bank website and login there then be bounced back to gov website.
Not sure how the system came to be but I'm very glad it's in place.
1) You redirect the user to the state 'identity service' with a specific token;
2) the user authorises either with their gov't ID card chip (less commonly used since most users don't have the chip reader) or with the bank of their choice (not all banks but most of the major ones are part of that scheme) for authentication;
3) the user gets a prompt like "company ABCD wants to get obtain the following data : Name, legal ID number" and can authenticate as normally;
4) you (as the service provider) get a response with your token, that legal ID number, and who authenticated that ID.
It seems quite reasonable - it provides a reasonably secure way of verifying someone's identity (preventing e.g. the SIM-porting impersonation scams that seem to be a problem in USA) without giving anyone the ability to impersonate someone (the ID numbers aren't considered secret like USA social security numbers - they're PII so there are restrictions in storing/using them, but knowing them isn't sufficient to so anything).
Our goals then we’re to be an identity provider. We were not the only ones trying at this—-personal.com was much better funded and tied into DC—did nothing interesting but also hoped to store personal data securely and make it available when users desired to share.
We hunted use cases for identity like the Predator. Pivoting into secure messaging, Bitcoin, and finally a marketplace. But could not find a way to make it work.
Building identity in the vacuum of a useful and popular service doesn’t work. At least, we were unable to make this work.
https://www.engadget.com/2012/08/14/gliph-launches-new-cloak...
At the time privacy was a thing that seemed possible to monetize. Over time that is true but it comes “for free” at the platform level now to some extent with Apple.
We wanted ultimately to get paid from companies seeking personal data from their users. Users would allow it, then we would federate the data and co would pay for the privlidge.
But if you can have decentralized apps where the app writer is decoupled from the app hosts (miners on Ethereum or similar), then there is a market for basically a identity+locker service sold directly to consumers.
You need a cadre of great already written decentralized apps for that market to make sense, and we are possibly still 10 years away from that day.
PhD students smarter than either of us are scratching their heads literally right now to even describe that first wave of apps. Five years til they defend their dissertations. Then the race is on.
Can you expand on this? I don't see how that conclusion follows.
With distributed apps, the app writer doesn’t host their app, it’s hosted by random miners all over the world. This makes open source hosted services suddenly very easy for individuals to write. You don’t have to start a company to host your service, you just have to write it. Similar to the olden days when you could just throw up a tarball on a FTP site and millions of people could use your app.
So it’s a very lightweight social structure holding up the nuts and bolts of running the service.
However that creates a problem: there’s no trusted party there who is actually unlocking your data and assuring you and other that you are in fact you.
If you have super duper OpSec skills, of course you can just maintain your private keys, get a safety deposit box for your backup tokens, etc.
But for normal users that won’t be an option, so this space of open source decentralized apps will create a market for someone to provide at least basic identity services: holding backup keys, resetting your passwords, revoking session tokens, etc. And once you’re doing that you might as well throw in drivers license validation, group level data access control, etc.
The entire existing global payments system would not function without verified identity.
Healthcare would not function without verified identity (both for payment but also for tracking treatments and outcomes).
Existing marketplaces often require verified identity (as it helps combat fraud).
Vehicle license plates depend on verified identity (and are part of a system to enforce that).
Border control requires verified identities.
There are so many places in our current society where verified identity is essential, and already a solved problem (yes the solutions aren't perfect, but they are in place). Bitcoin failed IMO precisely because it actively avoids tackling identity, which has been a central part of finance for as long as it has existed. It might be hard to usurp the place states have claimed for themselves in verifying the identify of their citizens, or to make money from it, but it is absolutely central to how any society functions.
Identity is not dead just because some purveyors of online authentication think it would be easier not to deal with it. In fact I think identity not provided by states but claimed by the individual is a very interesting unsolved problem.
Fwiw, people have been hyping what an “interesting unsolved problem” identity is for a long time.
As far as I can tell, the existing solutions are more than good enough that any additional hacks are already built on top of them.
Identity is not dead, nor does it deserve to die.
Is there room for a corporate or distributed version of identity? Probably, but it might have to wait for the power of nation states to wane further, and it needs to acknowledge that identity is a core concern in many of these domains.
As somebody who has a startup in this space and growing, I'd love to hear more from your experience, my email is on my account page, shoot me an email.
We didn't take the crypto/blockchain approach at Truework. In our case, we started from a use case with verified identity needs and we are going towards a more generic identity management system.
Truly there are almost zero situations in which an entity needs to know your real identity. You bank, surely, but you go into the bank to do that.
Single Sign on via Google and FB is now normative because they're ubiquitous and convenient, and of course, FB id's come with a greater possibility of legitimacy, and nice FB pixel marketing data.
I suggest that thre is something that could work, it just needs to be put forward by a credibly entity that for whatever reason feels it's in their interest, whereupon those interests are not entirely conflicted with the individuals right to privacy.
But then websites don't get their FB pixel data, can't retarget and build ad audiences. FB also does some heavy lifting in terms of managing forum comments, which can be useful in some specific situations.
As long as people are willing to click in the FB/G sign in buttons, I think they'll be there to use.
I suggest the biggest opportunity for change may come in the form of regulation and legislation.
That's in the US only. The Rest of the World value is much lower.
1000 percent this!
What entities really need to know to do their function is shockingly small compared to what they ask for. Here are some examples:
- Bank: proof you are authorized to make decisions for a given bank account. (Possibly jurisdiction info if the government forces banks to screen on citizenship.)
- Voting: proof that you didn't vote twice. (Possibly jurisdiction info if you are only allowed to vote in a specific area.)
- Job: a nickname, contact info, where to send compensation, a way to grant (and revoke when terminated) your access to non-public information. (Possibly jurisdiction info if the government forces companies to screen on citizenship or calculate taxes in a specific way.)
- Social media network: way for others to connect with you (eg email).
- Bars: (possibly proof of age, if the government forces establishments to limit sales on that basis.)
- Online or in-person payments: proof that the funds transferred to the business's account.
99% of online services doesn't need my real identity but the ones that need it definitely aren't almost zero.
E.g. Some medical services may need to know your medical history. Others need just some token that lets the bureaucracy figure out who to ultimately bill for it. Leasing/crediting services - well, they'd love to know everything about you, but that doesn't mean they should get it.
My point is: these services may require identity, but they don't truly need it, could work without it, and it's only a bad design that they do ask for it.
What if you apply for a state benefits (e.g. benefits for your children, or student state grants)? These kind of services being accessible online are common in the Nordics and when authenticating the service provider would need to know a lot of personal information such as name, age, adress or email, previous given benefits records from other service providers, current loan debt status, university registration status, bank account nr, family members etc...
Zero knowledge proof in identity is a thing, but then the assurance of identity falls on a third party that has to verify your identity. There is also Self-Sovereign Identity and user-centric identity management which many consider the future of identity. But even in that case, most often a third party needs to at least maintain the infrastructure of where your identity is stored.
The best solution in this case is to stop means testing them, and also convert every plausible benefit from stuff to cash-to-buy-stuff-with (i.e. UBI). Because at that point it's the same as voting, all you have to prove is citizenship and that you haven't already received the benefit, there is no separate eligibility information required.
People have the intuition that not means testing things would be expensive, but when the benefit is in cash that comes out in the wash. If you receive $5000 more in cash than the value of the benefits you were previously eligible for, but then have to pay $5000 more in tax, it just cancels out and you're back to the original situation. Only now nobody has to prove eligibility status outside of basic citizenship, which also greatly reduces administrative costs and fraud.
How do you prove you did not receive something?
How would someone do that? How do I prove that I am right now here, to someone else that's not physically present?
On a related note, how do I, right now, while doing this activity, prove that I belong to this jurisdiction, and not others.
Important when buying weed online, for example.
What if that address is a mail forwarder? How do you prove that I reside at the delivery address?
As for determining your jurisdiction, that usually means residency, which off the top of my head could be minimally verified by govt proof via (redacted) taxes filed in that state.
And when it turns out that you've employed a convict for 2 years? Who also happens to pass your "jurisdiction info" check.
Probably you should be allowed to keep quiet about qualifications that you don't want to claim. I read about a case in which a factory worker was sacked with the justification that they had failed to declare their university degrees when applying for the job. They had a degree in politics and the employer believed (probably correctly) that they had got the job specifically in order to be a trade union activist. However, whether that ought to be a valid reason for dismissing an employee is another question.
> 1000 percent this!
> What entities really need to know to do their function is shockingly small compared to what they ask for. Here are some examples:
> - Bank: proof you are authorized to make decisions for a given bank account. (Possibly jurisdiction info if the government forces banks to screen on citizenship.)
> - Voting: proof that you didn't vote twice. (Possibly jurisdiction info if you are only allowed to vote in a specific area.)
> - Job: a nickname, contact info, where to send compensation, a way to grant (and revoke when terminated) your access to non-public information. (Possibly jurisdiction info if the government forces companies to screen on citizenship or calculate taxes in a specific way.)
> - Social media network: way for others to connect with you (eg email).
> - Bars: (possibly proof of age, if the government forces establishments to limit sales on that basis.)
> - Online or in-person payments: proof that the funds transferred to the business's account.
But for all of these use cases, who would be the provider of these attributes to the third parties? Haven't we already seen issues with centralization of identifying information? (Like the case with the OPM breach?)
What is my 'real identity', honestly? How does a bank prevent me from opening an account in the name of my hypothetical identical twin if I borrow the appropriate documents? How would a government agency?
The reality is that identity winds up being evaluated as a relationship. My bank identity is as a particular customer, and me attempting to opening an account in someone else's name doesn't change that - rather, it is a sign I as a customer am planning to commit fraud. In some fashion, a process attempting to tie an interaction to an identity is actually attempting to tie behavior to consequences.
This made the article a bit difficult to understand - was the point that the sharing of identity, and thus trying to die back to one 'true/real identity', is flawed?
Or perhaps that this concept of local identity isn't always needed to perform a transaction - I don't care who a customer is as long as I know the information that I'm acting on is true?
Single Sign-on itself is an often abused topic - it generally means that authentication (providing proof that you correspond to a particular identity I hold) is reused.
However, Federation is the process of sharing that information across domains, and is usually done via protocols like OpenID Connect or SAML.
Google Sign-In, Facebook Connect, and other IDPs usually combine both - and the value comes not from signing in with google credentials, but that you often already are signed in with google/etc credentials.
The value you get back contains a subject attribute, which is a unique (possibly globally, or perhaps only within your service) identifier for the user account upstream. This value is what turns these social logins to an authentication for your own site or app.
At the minimal level, the information leakage is mostly to the IDP - they see where and when you are authenticating. However, the IDP is free to offer whatever additional attributes and authorizations they decide to - verified email addresses, API access to user data, and so on.
Possibly, the IDP even shares some piece of information your service might rely upon because you consider it the user's 'real' identity.
Think about shopping at Amazon where they get a payment authorization from your bank and a shipment authorization from your shipper and never know your name, your bank account number or even your home address. It's technically very doable...the problem is that there isn't much incentive for Amazon to let go of all of that metadata.
I think there's some ideas going around that might work here.
Make companies responsible for securing that data, and make it _expensive_ if/when they get breached. Make storage of personal data "toxic", so companies will _only_ keep it for the minimum amount of time required for whatever use it was gathered (where only companies like FB & Google, and to a lesser extent Amazon would admit to themselves that it was collected for the express purpose of creating a historical record of individually identified PII).
Here (in .au) we have "mandatory breach disclosure laws", which while having fewer teeth that I'd personally prefer, and a reasonably useful "first start", they're quite useful in the context of discussions around "So why are we asking for cusomer's date of birth? Is that something you'd want to explain in a mandatory breach report if our database gets hacked?" and "So what's our retention policy on this data we're collecting? Forever? Really? What's our plan around reporting data breaches, and do you want to ever have to explain why we've got 5 years worth of records breached when we only needed to store that data for 90 days after which most of the details were never needed again?"
I'm _hoping_ sometime soon the GDPR is going to quite publicly go through it's due process, giving some company every chance to become compliant, be continually ignored, and then eventually hit them with an eye-wateringly big existentially threatening fine that the offending company has absolutely no grounds to claim it didn't know about, didn't have several appropriately escalated warnings, and were just blatantly abusing their users personal data without any regard for personal privacy or European Law - and have zero public support for their complaints about the fine.
(Personally and perhaps somewhat pettily, I hope this happens to Uber or Facebook, but pragmatically I'd settle for anything matching that description, to "pour encourager les autres" and for use in meetings and documents when clients or cow orkers suggest doing shady things with other people's personal data...)
You're assuming they won't just mitigate the risk by spending more on securing the data and then still keep it all and hope their security is enough to avoid getting pwned.
Moreover, many smaller entities won't even bother with trying to secure it and then just hope it doesn't happen to them and declare bankruptcy if it does. Some of which will just have had no idea the liability even existed to begin with because they don't read HN and didn't have the money for lawyers.
The solution to this is better when it comes from the demand side. People should refuse to give this information to these companies; then they won't have it and can't use it for anything nefarious. So the question then is how to convince people of that.
Certainly a good first step would be to eliminate any existing rules that require companies to collect this type of information on people.
Yeah. That's one place we here in .au are fucking ourselves over. As well our mandatory breach reporting laws, we _also_ have mandatory meta-data retention laws. It you're an ISP (which thankfully I'm not), you are _required_ to retail all you user's metadata...
1) to make it easy to verify if they're trustworthy based on past experience;
2) to make it easy to identify and prosecute them if trust is breached;
3) make it difficult for them to 'start from scratch' if they deservedly gain a bad reputation;
Currently the vast majority of e-commerce happens through credit card networks on principles that essentially can work only because it's very hard for CC merchants to be anonymous.
Also, if I'm entrusting my data to some service, I do want the operators of that service to be not anonymous - if it is easy for them to escape liability for misusing that data, then that significantly raises the risk that they might actually misuse that data.
A lot of useful things in our society require or assume trust. Anonymity weakens trust; accountability through clear, unescapable identity strengthens trust.
Also, people want to be themselves - and want others to be themselves even online, for a multitude of reasons too, personal fame being one. A few rightly sees this a privacy risk, and resolving this conflict is the real unsolved issue.
Identity verification is largely solved in countries where the government (in some cases via banks) backs such services. The US lags behind, but that's another issue.
No, but nice try. Maybe in some circumstances, maybe even several, but this isn't THE concern online. Anonymity is not always bad.
Anyhow my main issue with what you've said is how you've glossed over how you think the author is wrong. What are some reasons attributes are a poor substitution for identity as described?
We're a long ways from that sort of thinking of course. And on that note, there are still an estimated 1.1 billion people in the world lack any recognized formal identity. There's a chance for many of them to leap frog us by going straight to digital identities rather than carrying around cards.
Exactly. Anyone who has had to deal with the OFAC list (which in reality is every single business in the US) knows that the more information you collect up front, the less disruptive of a user experience you can guarantee (for most users).
Verifiable claims in this context does not alleviate the need for Identity, it merely offers the ability to shift it to a third party. This is not a silver bullet, and depending on the use case you might prefer a bilateral transaction rather than on with a (designated mandatory) third party. While you might be happy that you can escape an over-inquisitive due diligence procedure of a party you suspect are collecting your personal data for reasons beyond the provided service, you might be less keen of needing to disclose a limited personal transaction to a central instance under the form of 3rd party attribute verification.
> We're a long ways from that sort of thinking of course. And on that note, there are still an estimated 1.1 billion people in the world lack any recognized formal identity. There's a chance for many of them to leap frog us by going straight to digital identities rather than carrying around cards.
KYC literally means "know your customer". In what ways do you think that identify is superfluous to this notion? The purpose of KYC is not limited to hindering or prohibiting money laundering.
What other legitimate purposes does it have?
As an example: I'd love to be able to allow (and then revoke) Amazon's knowledge of my name and street address, but in the absence of GDPR-style regulation with real teeth (or the ecosystem being so mature as for Amazon to request delivery of a black box to identity XYZ and have some other company request permission and fulfill it) there is no incentive for them not to store anything I give them for eternity upon gaining access once.
Digital systems traffic in identifiers -- strings of some sort, usually, which purport to identify one and only one ... something. A person, a business, a role. The holy grail is that no one such identity (the actual behind-the-identifier entity) has multiple identifiers, though this always fails, least of all because developers and authorities require flexibility.
What identifiers actually track, mostly, is relationships, between some individual, and ... well, some interested party. Are you a homeowner, patron, customer, insured, user, employee, employer, vendor, client, ...? And here, a large part of the conundrum becomes apparent: relationships differ depending on the relation between entities, a single individual has many relationships, possibly (or probably) with even a single other party.
Much of the attempt to track identity comes down to credit (or creditability), rights, trust, entitlement, responsibility, or other ongoing relationships over time. Are you the individual who has a legitimate claim to the contents of a bank account? Or a data storage account? Are writings A, B, C, and D the work of one or multiple individuals? Is that individual (or individuals) credible? If I want to listen to a musical performance, do I owe you a payment? If you listen to a musical performance of mine, how do I assert, and correctly collect on, a payment claim? Are you claiming to be A but are actually B? Is this transaction potentially fraudulent?
Some claims are more enduring and critical than others. Entitlement to a pension or government social insurance claim. Tax liabilities (or refunds). Voting. Others are inherently limited -- for all the risks of fraud in commerce, once a transaction has conclusively completed (and the tax office gets its vig), identity is largely moot.
(Service-based relationships change this, though whether that's worth the hassles is another question.)
In-person assertions of identity, as with voting, are expensive to spoof, particularly at scale. This is why the interesting acts of voting fraud very, very, very seldom involve individuals voting multiple times -- the costs are too high given the desired benefits. Far easier to corrupt the process elsewhere: eligibility, ballot formats, voting places, counts, and the like.
The power and curse of digital information it is independent of presence. Actions can be taken independent of place, and often of time. One work-around is to require an in-person registration at some periodic interval, or anchoring to a specific location (as with mailing addresses), or to payment. That last is why financial transactions records are so hotly sought: there's literally a cost to creating these, hence they're vastly higher quality than other data. (In the data analysis world, data tied to payment is virtually always more reliable than data which isn't: in U.S. health care data, procedure data, on which payment is based, is far more reliable than diagnosis. And since payments are contingent on both, each is gamed (through physician billing coding software) to maximise revenue.)
- identity requires the ability to bear risk.
- an identity not blessed by government bears very limited risk.
- the use case for government issued identity is only in enforcement (fines, taxes, service eligibility, etc.)
- The private sector does not need "strong," identity for anything other than credit/collections, for which banking IDs are the legitimate portal to govt identity today. There isn't a consumer driven use case for "strong" identity.
- "strong" identity reduces to being sufficient to target that person with court ordered violence. Everyone talks around it, but that's what they mean.
- an alternative strong identity provider is a de-facto state. (looking at you, FB/AAPL/GOOGL)
The attribute based models are technically interesting, but what we are really talking about is equivalent to financial instruments and securitization of identity.
The quality of any given individual identity assertion can bear up to a certain amount of risk. A tranche of identity assertions can bear even more risk, as the failure of some does not significantly impact the rest of them, and the cost/benefit of accepting the tranche is greater than the projected loss.
Futuristically speaking, the most likely identity technology two decades from now will be a set of collateralized attributes tied to securities, and ones that are asserted as bearing risk up to a certain grade. The rehypothecation or leverage on that identity will be a part of its score, which relying parties will assess and request additional collateral on accordingly. It sounds complicated, but it's not.
What such a "securitized," identity (so-called anonymous ID) breaks is the income tax and other individual enforcement use cases, where transaction taxes are viable, but tying them all back to a single state issued identity becomes unfeasible. The trade off is like the one we're encountering with cryptocurrency today, where it's useful for everything except state approved markets.
What's most likely is that innovation in identity will happen in countries where mature public services that require income taxes are not an impediment. e.g. the way that "developing," countries leapfrogged rich countries on wireless telecoms because they didn't have sunk costs in copper infrastructure, similar countries will leapfrog rich countries on digital identity and commerce because they don't have as much of a sunk cost in a strong government identity-based taxation model. When you look at how taxation works in resource-based (oil) and tourist (island) economies vs. services economies ("on shore"), they have more opportunity to facilitate digital identity services.
Identity is not dead, it's just that identity is not about identity.
1. ANyone with a public key can become an identity provider. Services will only work with a list of authorized providers, though. The list should be supplied by the govt, or some external, trusted org (like Visa for credit cards). When authorizing, data management policies and security should be reviewed, and policies should be enforced, i.e. how claims are verified, ability to port out to a different provider etc.
2. Organizations like the government would have some number or token, and the provider used by every citizen. Information about them, like their age, them being convicted, having unpaid depts etc. would be sent as cryptographically signed claims to the provider. To be authorized, a provider must promise to not reject any valid claims.
3. When authorizing with an external service, a request should be sent to the user's provider. Then, the user should be authenticated to it, shown what the service wants, and, upon approval, the request should be fulfilled.
4. Services would usually request assertions (fail if the conditions I've just sent you aren't true). Assertions could include:
- The user must have an age claim signed by the govt where age > 18.
- The user must not have a valid "has some credit problems" claim.
- The user has a citizenship claim from the state of California or the state of Nevada.
- The user doesn't have a "convicted" claim where date of conviction >= 2010.
- the user doesn't have a "banned" claim, signed by me. As a blog author, I could use that to not identify users across visits, but block spammers easily. - The user has a "personalInfo" claim from a government. This would be used to ensure that, in case this user does something really bad, a court could force the provider to link the token given to us to a specific, living person.
5. Services could also request capabilities, like the capability to send information to the user (without getting their email address), to get the same token across visits (which wouldn't be the default), to transfer $15 every month from their account for the Netflix subscription.
6. If there was no other way, services could also request access to information, like the user's home address for a pizza delivery service, or the user's location for Uber.
7. All requests could be one time or continuous.
8. All services would need central authorization for getting any sensitive data.
This model wouldn't make the user experience suck, provide the companies with what they need, and npt expose too much data unnecessarily.
It also assumes that users providers will be forced to store information on your behalf (such as the knowledge that the user has been banned).