Reading more of the discussion about Identity Oracles, I've come to agree with the importance of having separate names for the business model and the underlying technology that would be used to deliver services. So I buy Dave Kearns's advice:
Drop it while you can, Kim. Bob's right on this one. The “Identity Oracle” is a business model, not a technology feature.
Why was I conflating things?
Well, when we were devising the technology for claims transformers, we were specifically trying to enable the scenario of providing answers to questions without releasing the information on which the answers are based (in other words, support derived claims). We intended the claims transformer to be the technology component that could supply such answers.
I saw the name “Identity Oracle” as describing the scenario.
Now I see the advantages of having very precise naming for a number of interrelated things. It can leave us with this taxonomy:
Reading Dave Kearn's post on how a service like HealthVault might evolve in the direction of an Identity Oracle, I couldn't help wondering about the problems of liability implied by some of these behaviors.
For example, consider a health-related Identity Oracle that could answer the question, “Can Kim take drug X without fear of drug interactions?”. The resultant “yes” or “no” would be a lot more privacy friendly than releasing all of Kim's drug prescriptions and the medical information necessary to adequately answer the question.
However, the Identity Oracle presumably assumes more liability by “selling” its “yes” or “no” conclusion than it would by releasing simple facts (assuming the right permissions and use restrictions were in place).
In other words, success of this model will involve a transfer of liability from the party currently making a decision to the oracle. This liability has to be factored into the cost structure of the identity oracle business model, and the resultant pricing must make sense to the requesting party.