Identity Is Dead(constellationr.com)
constellationr.com
Identity Is Dead
https://www.constellationr.com/blog-news/identity-dead
88 comments
> 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.
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.
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.
In Belgium we have had the eID for years. Our national ID cards are smart cards. The idea of having to rely on private institution such as credit card issuers for identity seems ludicrous to most here.
https://eid.belgium.be/en/what-eid
https://eid.belgium.be/en/what-eid
IRMA has existed for a while, it's a non-profit spinoff from a Dutch university. But to my knowledge it is nowhere as widely known or accepted by relying parties as DigiD[1], this system is run by the government and based on passing the BSN (citizen service number)[2] to the relying party with SAML. It exists since 2005 and has become quite widespread: I can use it to file my taxes, make an appointment at pretty much any municipality town hall, and log in to my health insurance provider to name a couple of things.
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...
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...
We can't have one of those in the US because lots of people are afraid that it will be the "mark of the beast" from the book of Revelation in the bible.
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.
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 the US there has been widespread pushback about national id. Civil liberties folks don’t like big brother, immigrant advocates fear making it impossible for some populations to drive, and the conservatives worry about states rights, especially with respect to voting.
I can't ascribe good faith to conservative concerns anymore. It's absolutely insane that federal elections aren't standardized across the states.
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.
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.
Believe me, I don't. But the success of people who are dedicated from keeping poor and brown people from voting is enabled by others with perhaps better intended but equally inflexible intentions.
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.
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.
> Now, I agree in theory that bank accounts for example may be regarded as “identities”, and it follows that banks could be regarded as “identity providers” (IdPs). But these conceptual models have proved sterile. How many banks in fact see themselves as “identity providers”?
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.
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.
We have the same here in Latvia. There's an integration process available also for private services that essentially has the following workflow:
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).
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).
Same here in .nl, you have a government digital id called Digid, but it’s just a login and password with optional sms 2fa, but we also have IDIN, which uses your banks hardware token, etc, to identify, which is better.
[deleted]
Same here in Sweden with the BankID system which I can use to 'sign' things on my mobile device, for example to do my taxes online (usually tax forms are pre-filled, so I only have to double check that it's correct), and do many other things. https://www.bankid.com/en/
I'm not so glad as this kind of integration is a huge threat to privacy. You should know you're not allowed to use public services you described if you will not provide your mobile phone (it looks like it's a civil duty to have one now). So you're tracked on each step literally.
I thought Civic (https://www.civic.com) was one of the most interesting projects to come out of the blockchain space for secure identity, but haven’t really seen it adopted anywhere. Facebook sign in is everywhere, but Facebook is also completely untrustworthy when it comes to personal data and so I tend to avoid it whenever possible. This idea of sharing attributes seems interesting but does it go any further than “This app wants access to your email address, contacts, and photos” that already exists?
Blockchains have very little to do with "secure identity", and in fact more frequently serve to damage the security of the individual. If everything is recorded in a central ledger, how long do you think it takes for oppression to emerge?
As opposed to being stored in Google/Facebook's databases? I don't know if blockchain is the answer, but I would prefer not to trust any of these large corporations and use a decentralized identity system where no third-party has control of my identity information.
In self sovereign identity systems based on verifiable claims, attributes are attested through signed claims on digital identifiers that the user control (e.g. a public key). Blockchains here are the most effective mean to implement claim revocation: if someone who produced a claim wants to revoke it, he writes that on a blockchain.
Disclaimer: I work for Hyperledger. One of our projects, Hyperledger Indy, is used in particular in Zug as the basis for an eVoting program. Searching for "Hyperledger Indy Zug" turned up some press releases and discussions about it
I was at the Napa identity conference referenced in the first paragraph. It was expensive but we were invited because of the unique identity work we were doing with our startup Gliph at the time.
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.
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.
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.
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.
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.
Not sure what your suggesting. Are you saying there is room for some new identity provider?
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.
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.
I'm suggesting that, contrary to the article's thesis, bitcoin's thesis and the parent's assertions, identity is central to many core functions of our society and is not something to be elided or ignored.
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.
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.
You need decentralized apps for centralized identity to work I think. Ironic I guess.
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.
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.
> You need decentralized apps for centralized identity to work I think. Ironic I guess.
Can you expand on this? I don't see how that conclusion follows.
Can you expand on this? I don't see how that conclusion follows.
Google, Facebook, etc have so many apps and have so many users that it would be crazy for them not to control their identity systems. A team of 20 people maintaining OAuth servers is a rounding error for them. They tend to want as many moats as possible (not because moats are good, but because you have to be paranoid AF to grow to a multi billion dollar company.)
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.
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.
Who was your customer? Seems like that would be the hardest problem to solve.
We made the most money selling disposable emails, something we called Cloaked Email. It was similar to what Apple is offering soon.
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.
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.
Bredren -
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.
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.
I can only warn off from this direction. There is no product unless a core problem is being solved.
Identity, Single Sign On, and 'information gleaned for marketing' etc. are all different overlapping issues.
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.
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.
>Truly there are almost zero situations in which an entity needs to know your real identity.
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.
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.
Any online government/medical/banking/leasing/crediting service needs my real identity. In real world there are even more services.
99% of online services doesn't need my real identity but the ones that need it definitely aren't almost zero.
99% of online services doesn't need my real identity but the ones that need it definitely aren't almost zero.
They ask for it. They may currently require it. They don't necessarily need it.
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.
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.
No, all these services need my identity in order to offer me services that i want/need (my blood analysis results, bank account including cards/loans/leases, IRS, DMV, etc. Basically everything that is tied to my real identity and should be seen/accessed only by myself).
I am not from US so just using IRS/DMV as comparable examples. Third party ID providers or Government ID provider returns only my name and personal UID to all these services.
Most of the examples you listed require only an email address, PO Box, or a telephone number.
Maybe in the USA but i am not from there. All these services require to log in with your real identity at least once and depending on the service you can use it with your set up email address in read only mode, for example the DMV equivalent service allows you to see your vehicles, tickets (and pay them) and other info but in order to change vehicle owner you will have to log in with real identity provider.
I think we're still talking past each other.
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.
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.
I do agree that i could use anything (email, phone etc.) to login in those services but this "something" would be still mapped/tied to my real identity (in a previously validated way). So if it is the first time i am using DMV online service, i can login using my real identity because that is much easier than going to real world location and getting my account credentials.
> >Truly there are almost zero situations in which an entity needs to know your real identity.
> 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?)
> 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?)
>1000 percent this!
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.
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.
> What if you apply for a state benefits (e.g. benefits for your children, or student state grants)?
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.
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.
Perhaps you are right, but we have to create systems for the needs of today's society as well, and in today's society you need to be eligible for a certain benefit in order to get it. Therefore, we need a person's identity (with all the personal information that are required for such eligibility to be checked) when that person is authenticating online and applying for that benefit.
> 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.
How do you prove you did not receive something?
How do you prove you did not receive something?
How do you prove that you did not already receive a government ID, and go back and get five more with different names and numbers on them? Same question, same answer.
This is good stuff but in one case at least - jobs - add to your list the need to perform background checks during the application process, which does require an actual identity verification.
Background checks? Maybe if you're joining the secret service. In most cases the employer just needs to check that the qualifications you claim to have are genuine.
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.
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.
Amusing story! But in some countries (not sure about the US) it is common to perform a criminal record check, credit check etc. on new employees. In high compliance environments (e.g banks) the checks may span any countries you have resided/worked in for the previous few years.
> jurisdiction info
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.
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.
Given the verifier has physical control over the location in which the verifiee must verify themself, it's trivial to ask for info only accessible from that location at that time.
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.
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.
Your delivery address proves your jurisdiction in case of weed.
> Your delivery address proves your jurisdiction in case of weed.
What if that address is a mail forwarder? How do you prove that I reside at the delivery address?
What if that address is a mail forwarder? How do you prove that I reside at the delivery address?
I am just speculating but if they don't provide door to door delivery then you probably have to upload whatever documents they need defined by law. This clears them and it doesn't matter that they are sending stuff to a mail forwarder as now you are committing a crime.
That would work but would suck when you wanted to know who did what. Makes me think about: if all in a team has responsibility then no one has.
> Jobs
And when it turns out that you've employed a convict for 2 years? Who also happens to pass your "jurisdiction info" check.
And when it turns out that you've employed a convict for 2 years? Who also happens to pass your "jurisdiction info" check.
Convicts being able to be employed is likely a net good for society at large. There are also countries where asking whether someone was ever convicted of a crime is not the default and they are fine.
All of those (except bars and social networks) also need a postal address where legal and court documents can be served.
Or invert the push requirement to a pull one: instead of citizens being required to give a valid method of immediate contact, require that they check for new messages at regular intervals. Failure to do so would be the same as ignoring push notifications.
Identity is a somewhat philosophical and thus nebulous concept.
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.
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.
I'd argue that in pretty much every transaction where trust is involved (all e-commerce, and not only that) I'd want to know the other party to be not anonymous so that it's possible to combat breach of trust:
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.
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.
I think there's a lot of room for a faceted identity model in which the user is in control of what attributes get shared.
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.
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.
> 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...)
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...)
> 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).
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.
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.
> 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...
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...
Thoughts on Apple SSO?
It's too early to tell, but because they have such a wide reach and own 1/2 of mobile, if they push it hard and it's a clean enough solution it may just work as a relatively 'privacy first' orientation.
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.
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.
> and own 1/2 of mobile
That's in the US only. The Rest of the World value is much lower.
That's in the US only. The Rest of the World value is much lower.
Well none of these social media SSO supports a high Level of Assurance anyway.
Zero knowledge proof
No, but nice try. Identity is not dead, and attributes are a poor substitution for identity in a number of circumstances, for a number of reasons, too many to enumerate - but prosecutability maybe being the main one.
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.
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.
> "Also people want to be themselves - and want others to be themselves..."
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?
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?
Even with banks, what they really need to know is that you are not laundering money and you pass KYC checks. Verifiable claims would be a way to pass those checks and get a bank account without the bank needing to store any of your personal info.
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.
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.
A bank needs to be able to recheck every client's status any time the rules change (which happens on a weekly basis). If they don't hold adequate information about their clients, that would mean suspending their accounts until a new verifiable claim was provided.
> A bank needs to be able to recheck every client's status any time the rules change (which happens on a weekly basis). If they don't hold adequate information about their clients, that would mean suspending their accounts until a new verifiable claim was provided.
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).
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).
This is a bit disingenuous. KYC applies to the person/organization, not merely the role of counter party in a certain transaction, and has many use cases besides AML (AML regulation is externally forced on financial service providers as frankly they do not care, commercial exposure, both in terms of financial risk or brand image protection, is another thing which they do tend to care about more).
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.
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.
> Even with banks, what they really need to know is that you are not laundering money and you pass KYC checks. Verifiable claims would be a way to pass those checks and get a bank account without the bank needing to store any of your personal info.
> 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.
> 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.
> 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?
What other legitimate purposes does it have?
Preventing transacting with known "terrorists" as according to the OFAC list (in the US at least)? That's just one other legitimate purpose.
This is one of those scenarios where it could be amazing if the whole ecosystem were mature from top to bottom, but the incentives aren't really in place to have it happen naturally.
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.
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.
Don't expect it to go out without a fight.
"Identity" is who you are, not something you have. It's not an attribute assigned by some other party.
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.)
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.)
Worked on digital identity for government services in a variety of ways (public and private sector) and its applications in broader society some years ago, here were my findings:
- 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.
- 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.
I think we don't really need identity, per se. What we really need is a system like this.
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.
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.
Don't forget a transparency log visible to the person, where it would be possible to audit who requested what assertions and what authentications were made, etc. This may even be public information (some statistics on what companies request what assertions) - to put pressure on not requesting needless crap.
You would also need a GDPR requirement that the user doesn't have to provide info he doesn't want to, and that is not a reason to deny service (e.g bar doesn't get to demand your age, only above 21 or not).
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).
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).
This should be part of authorization, as I've said before. ANy provider proved of commutting fraud in that aspect would need to be banned, immediately. THis wouldn't even need to be a law, simple, app Store like guidelines would suffice.
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...