The page has unconfirmed changes. Use the buttons below to see older versions.
The idea of idplace.org, a provider of unique IDs using OAuth
Link:
https://idplace.org
I think the image best explains how other ID providers fails in one way or another.
Why is uniqueness (sometimes) necessary
Imagine a taxi-app that lets people login and appear as taxi drivers. If one don't make sure that the ID is unique, it will quite soon be those resourceful drivers who creates like hundreds of ID's and thereby gets way to much market exposure relative to other drivers, and thereby the taxi-app would effectively be sabotaged.
Why is it important not to bundle to much other data with the ID (like Facebook etc do)...
...because people are reluctant to use these accounts because they have so much other personal data stored with them and they feel that they can't be certain of what data is being shared. The role of ID-provider should be separate from the role of social-media-provider / discussion-forum-provider.
One day this might change, and people become more confident with using for example Facebook for logging in. But still I think there are room for multiple ID-providers.
So the idea with idplace.org ...
... is to have an ID-service that take some extra steps to ensure that the ID is unique. Of course it is not possible to be 100% certain that no fake accounts slip in (even Facebook says that a few percent of their accounts are fake).
I think that if you make it clear to the users why it is important to prevent fake-accounts then they will accept that you ask for data such as National identification number (social security number), and perhaps also compare the data to external databases with the sole purpose of filtering out fake accounts.
To assure the users integrity, one should also make it very clear that the user can delete his own account at any time. And by using open-source / free code, one can verify how the software works.
How to maintain the register and to find / prevent fake IDs
Idea 1, relaying the problem to the end users:
To relay the problem to the relying-party-site (the taxi-site using the taxi-example), who in turn can relay the problem the end-relying-party (the taxi customer). With all the possible places where one can express oneself today (like comment sections etc.). It is quite likely that cheaters will end up in the spotlight eventually.
1) How users with multiple accounts can be found.
One could do like Facebook and ask for what "networks" they have occurred in (what schools they went to, what workplaces they have worked in). This is something that the public (other users) are able to check out and maybe also help out to spot fake ID's.
2) How users who aren't consistent with the data they supply can be found.
(Example: A user may change the settings to be Swedish in a Swedish referendum then switching to be Norwegian in a Norwegian referendum.)
To deal with this problem one can store the time point when a piece of data was changed. It gives the age of different supplied data, like email-age, name-age, mother-tongue-age, nationality-age etc. And of course also account-age for when the account was created.
Referendum example: the referendum app (the site that presents the result of the referendum) can just summarize nationality and "nationality-age" in histograms and allow the end-user (those who want to see the result of the referendum) to sort/filter on those data. If the histogram shows a very large stack of people with very short "nationality-age", then it will most likely be detected by smart visitors and they can easily filter (sort) to get rid of those voters.
Taxi-app example: the taxi-customer could single out taxi-drivers who has for example long enough account-age. The account-age basically translates to reputation in the eyes of the end-customers. Ex: a taxi-driver with an account-age of ten years give much more confidence than an account-age of one week.
Idea 2, allowing users to login with other id providers (then relaying that info to end users):
Idea 2: An item you buy in a store may have different "badges" which makes it easier to hold manufacturers with brand names accountable for whether they actually do what they claim.
In a similar way a taxi-app could relay that an ID (a driver) is for example "Facebook-verified" with a badge.
A further way for the taxi-driver to increase the taxi-customers confidence is to tie his account with other OAuth providers with unique IDs (like Facebook), either at the ID-provider-level (at idPlace) or at the taxi-app level.
The account will get (sort of) boFacebookVerified=true, something that the taxi-app again can relay to the taxi-customer. It would sort of serve as a CE marking on stuff you buy.
Idea 3, purchasing other registers:
Another more direct way to get rid of fake accounts is to purchase other registers and compare to.
See also
idPlace_Terms_of_service