The concept of the Identity Oracle is something that I have been giving a lot of thought to recently. It has been driven by a combination of factors including current projects, maturity of both policy conversations and technology, as well as a desire to move the art of the possible forward at the intersection of identity and privacy. My intention is to use this blog post to provide pointers to past conversations on this topic in the community, and to use that as a foundation for furthering the conversation.
When it comes to information about people (who they are, what they are allowed to do, what digital breadcrumbs they leave during their daily travels etc.), there exists in the eco-system both sources of information as well as entities that would find value in utilizing this information for a variety of purposes. What will be critical to the success of the identity eco-system is to define, as a starting point, the qualities and behavior of the “entity-that-needs-to-exist-in-the-middle” between these authoritative sources of information and consumers of such information. I believe the Identity Oracle to be a critical piece of that entity.
So, what is an Identity Oracle?
- An organization which derives all of its profit from collection & use of your private information…
- And therefore treats your information as an asset…
- And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information…
- Thus keeping both the Relying Party and you happy, while making money.
That is as succinct a definition as I’ve seen in the many conversations on this topic since that time, and since I have no desire to re-invent the wheel, this is as good a starting point as any.
The key point to note here is that this is NOT technology but a business, and as such if there is any hope for this to work, this business needs a viable business model i.e. something that makes it money.
As Bob notes, some of the questions that need be answered by the current eco-system denizens such as Identity Providers, Attribute Providers and Relying Parties include:
- Paying for the Identity Provider server and the service it provides.
- Convincing Relying Parties that they should rely on information provided by a third party (the Identity Provider) rather than maintaining identity attribute information themselves.
- Assigning liability when a Relying Party asserts that a claimed identity attribute is incorrect.
- Assigning liability when a subject claims that the wrong identity attribute claim was released to a Relying Party.
- Making subjects whole when a security failure “leaks” subject identity attributes directly from the Identity Provider.
- Assigning liability and making subjects whole when a security failure “leaks” subject identity attributes from a Relying Party.
I will add the following to the above list:
- Making subjects whole when the Identity/Attribute Provider’s desire to monetize its visibility into the transactional information across multiple Relying Parties overrides its responsibility to protect the subject’s personal information.
As always, whenever something like this is proposed there is a tendency for technologists to try and map this to technology implementations. In this case technologies such as Security Token Services, Claims Transformers and Agents, Minimal Disclosure Tokens and Verified Claims. And in the “What the Identity Oracle Isn’t” blog post, Bob provides a clear example of why such a technology focused view is incomplete at best by walking through an example of an Identity Oracle based transaction:
A human - let’s call him “Bob” - signs up for an account with the Identity Oracle. The Identity Oracle collects some personal information about Bob, and signs a legally binding contract with Bob describing how it will use and disclose the information, and how it will protect the information against uses and disclosures which are not allowed by the contract. The contract prescribes a set of penalties - if Bob’s information is used in any way which is not allowed by the contract, the Identity Oracle PAYS Bob a penalty: cash money.
When Bob wants to get a service from some giant, impersonal corporation (say “GiCorp”) whose business depends in some way on Bob’s identity, Bob refers GiCorp to the Identity Oracle; GiCorp then goes to the Identity Oracle and asks a question. The question is NOT a request for Bob’s personal information in any form whatsoever (for example, the question is NOT “What is Bob’s birthdate”). And the Identity Oracle’s response is NOT a “minimal disclosure token” (that is, a token containing Bob’s personal information, but only as much personal information as is absolutely necessary for GiCorp to make a decision about whether to extend the service to Bob - for example a token saying “Bob is over 18”).
Instead, GiCorp’s request looks like this: “I am allowed to extend service to Bob only if he is above the legal age for this service in the jurisdiction in which he lives. Am I allowed to extend service to Bob?”
And the Identity Oracle’s response looks like this: “Yes.”
The Identity Oracle, in normal operation, acts as a trusted agent for the user and does not disclose any personal information whatsoever; it just answers questions based on GiCorp’s stated policies (that is, it distributes only metadata about its users - not the underlying data).
The Identity Oracle charges GiCorp and other relying-party customers money for its services. The asset on the basis of which the Identity Oracle is able to charge money is its database of personal information. Because personal information is its only business asset, the Identity Oracle guards personal information very carefully.
Because disclosing personal information to relying-party customers like GiCorp would be giving away its only asset for free, it strongly resists disclosing personal information to its relying-party customers. In the rare cases in which relying parties need to receive actual personal data (not just metadata) to do their jobs, the Identity Oracle requires its relying-party customers to sign a legally binding contract stating what they are and are not allowed to do with the information. This contract contains indemnity clauses - if GiCorp signs the contract and then misuses or improperly discloses the personal information it receives from the Identity Oracle about Bob, the contract requires GiCorp to pay a large amount of cash money to the Identity Oracle, which then turns around and reimburses Bob for his loss.
This system provides Bob with much stronger protection than he receives under national privacy laws, which generally do not provide monetary damages for breaches of privacy. Contract law, however, can provide any penalty the parties (the Identity Oracle and its relying party customers like GiCorp) agree on. In order to obtain good liability terms for Bob, the Identity Oracle needs to have a valuable asset, to which GiCorp strongly desires access. This asset is the big database of personal data, belonging to the Identity Oracle, which enables GiCorp to do its business. And allows the Identity Oracle to charge for its services.
The Identity Oracle provides valuable services (privacy protection and transaction enablement) to Bob, but it also provides valuable services to GiCorp and other relying-party customers. These services are liability limitation (because GiCorp no longer has to be exposed to private data which creates regulatory liability and protection costs for GiCorp) and transaction enablement (because GiCorp can now rely on the Identity Oracle as a trusted agent when making decisions about what services to extend to whom, and it may be able to get the Identity Oracle to assume liability for transactions which fail because the Oracle gave bad advice).
The important take-aways for me from the above are (1) The contextual and privacy preserving nature of the question being asked and answered, (2) the allocation and assumption of liability, as well as the (3) redress mechanisms that rely on contract law rather than privacy legislation.
This approach, I believe, addresses some of the issues that are raised by Aaron Titus in his “NSTIC at a Crossroads” blog post and his concepts around “retail” and “wholesale” privacy in what he refers to as the current Notice and Consent legal regime in the United States.
Currently, one of the things that I am thinking over and having conversations with others about, is if it makes sense for the Fair Information Practice Principles (FIPPs) [Transparency, Individual Participation, Purpose Specification, Data Minimization, Use Limitation, Data Quality and Integrity, Security, Accountability and Auditing], found in Appendix C of the June 2010 DRAFT release of the National Strategy for Trusted Identities in Cyberspace (NSTIC), can be adopted as the core operating principles of an Identity Oracle. And as noted in the example above, if these operating principles could be enforced via Contract Law to the benefit of the Identity Eco-System as a whole.
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.