In my last post I shared Jon Udell's conversation about “translucent databases” as a way to protect us from identity catastrophies. He mentions a lender (e.g. Prosper) who needs information from a credit bureau (e.g. Equifax) about a borrower's reputation.
I'll start by saying that I see the credit bureau as an identity provider that issues claims about a subject's financial reputation. The lender is a relying party that depends on these claims.
The paradigm currently used is one where the borrower reveals his SSN (and other identifying information) to the lender, who then sends it on to the credit bureau, where it is used as a key to obtain further reputation and personal information. In other words, the subject deals with the lender, and the lender deals with the credit bureau, which returns information about the subject.
There are big potential problems with this approach. The lender initially knows nothing about the subject, so it is quite possible for the borrower to pose as someone else. Further, the borrower releases someone's SSN to the lender – as each of us has given ours away in thousands of similar contexts – so if the SSN might once have been considered secret, it becomes progressively better known with every passing day.
What's next? The lender uses this non-secret to obtain further private information from the identity provider – and since the user is not involved, there is no way he or she can verify that the lender has any legitimate reason to ask for that information. Thus a financial institution can ask for credit information prior to spamming me with a credit card I have not applied for and do not want. Worse still, as happened in the case of Choicepoint, an important opportunity to determine that criminals are phishing for information is lost when the subject is not involved.
Jon proposed ways of changing the paradigm a bit. He would obfuscate the SSN such that a service operated by the user could later fill it in on its way from the lender to the credit bureau. But he actually ends up with a more complex message flow. To me it looks like the proposal has a lot of moving parts, and makes us wonder how the service operating on behalf of the user would know which lenders were authorized. Finally, it doesn't answer Prosper's claim that it needs the SSN anyway to submit tax information.
Another simpler paradigm
I hate to be a single trick pony, but “click, clack, neigh, neigh”. What if we tried a user-centrilc model? Here's a starting point for discussion:
The borrower asks the lender for a loan, and the lender tells him which credit bureaus it will accept a reputation from.
The borrower then authenitcates to one of those credit bureaus. Since the bureaus know a lot more about him than the lender does, they do a much better job of identifying and authenticating him than the lender can. In fact, this is one reason why the lender is interested in the credit bureau in the first place.
The credit bureau could even facilitate future interactions by giving the subject an InfoCard usable for subsequent credit checks and so on. (Judging by the email I constantly get from Equifax, it looks like they really want to be in the business of having a relationship with me, so I don't think this is too far-fetched as a starting point).
After charging the borrower a fee, the credit bureau would give out a reputation coupon encrypted to the lender's key.
The coupon would include the borrower's SSN encrypted for the Tax Department (but not visible to the lender). The coupon might or might not be accompanied by a token visible to the borrower; the borrower could be charged extra to see this information (let's give the credit bureaus some incentive for changing their paradigm!)
When the lender gets the coupon, it decrypts it and gains access to the borrower's reputation. It stores the encrypted version of the borrower's SSN in its database (thus Jon's goal of translucency is achieved). At the end of the year it sends this encrypted SSN to the tax department, which decrypts it and uses it as before. The lender never needs to see it.
All of this can be done very simply with Information Card technology. The borrower's experience would be that Prosper's web site would ask for an Equifax infocard. If he didn't have one, he could get one from Equifax or choose to use the oldworld, privacy-unfriendly mechanisms of today.
Once he had an InfoCard, he would use it to authenticate to Equifax and obtain the token encrypted for Prosper. One of the claims generated when using the Equifax card would be the SSN encrypted for the Tax Department.
When you use an Information Card, the identity selector contacts the identity provider to ask for the token. This is how the credit brueau can return the up-to-date status of the borrower. This is also how it knows how to charge the borrower, and possibly, the lender.
In my view, the problem Jon has raised for discussion is one of a great many that have surfaced because institutions “elided” users from business interactions. One of the main reasons for this is that institutions had computers long before it could be assumed that individuals did.
It will take a while for our society to rebalance – and even invert some paradigms – given the fact that we as individuals are now computerized too.