Yvonne of Sun has some very good insight into the issue of derived attributes in an Identity Oracle context here. Phil Hunt has some interesting thoughts about Identity Providers here. Both of these look at different aspects of being an Identity Provider or Oracle in practice. Yvonne raises the excellent point about what happens when the data used for the derived attributes is erroneous.
I was thinking recently that we have a very good example of something like an Identity Oracle today where there is a clear and successful business case: Credit Bureaus. This is ironic because answering questions derived from credit ratings is a common example cited for credit ratings. Supposedly an Identity Oracle could derive an attribute indicating your ability to handle a loan based on your credit rating, which itself is a derived attribute.
So what is interesting here?
- The Credit Bureau has a derived attribute (credit score) which is derived from a multitude of sources of information.
- If one of those sources is wrong, it becomes the user’s responsibility to try to correct it.
- The Credit Bureau has a very profitable business being an identity oracle
- The SPs really have only a tenuous business relationships with the Credit Bureaus.
- The user supposedly has control over the release of his credit score. But the user is often forced to consent to release this information for both important and not so important business transactions. Many users are not even aware that they have consented to release their credit scores.
- Most people pretty much hate the system.
So how do we prevent Identity Oracles, if there ever are any, from becoming like Credit Bureaus? Regulation is clearly not the answer since Credit Bureaus are already heavily regulated and people hate them.