Anil John
Making Digital Services Secure and Trustworthy

Anil John

Identity Oracles - Trust is Ephemeral, Contracts are Eternal

 Share  Print  Email

In many conversations I have had with folks who potentially have a need for the services of an Identity Oracle, especially as to how it could help with assurances of identity, there is a two part reaction that I found to be very interesting as indicators of what we need to focus on as a community to make this real and viable.

The first part of the reaction is typically about the “many security holes” in the concept and “changes to existing business processes” that are needed to leverage the capability. The second part of the reaction takes place a bit later as we get into discussing identity proofing and bring up the example of US Government PIV cards (which are Smart Cards that are issued to US Government Employees and Contractors) or Non Federally Issued PIV-I Cards, both of which have have transparent, publically documented, and consistent identity proofing process and the level of comfort the same set of folks have in potentially changing their business processes to accept the PIV/PIV-I Card as a proxy for identity proofing that has been done by someone else.

What that combination of reactions confirmed for me is that the issue is not about technology/security holes (since the the Identity Oracle is a business and NOT a technology) or about changing business practices (since the second part requires that change as well) but about the level of comfort and confidence one can place in the relationships between the Identity Oracle and entities that need to interact with it. I prefer to not use the word “Trust” in this context because the definition is ambiguous at best (See Gunnar Peterson’s “Lets Stop ‘Building Naïveté In’ - Wishing You a Less Trustful 2011” blog post) but instead would like to focus on the contractual aspects of what can be articulated, measured and enforced as both Gunnar in his blog and Scott David in my earlier “Identity Oracles - A Business and Law Perspective” blog post noted.

This tension between the technical and the business also came up in the reactions (@independentid, @NishantK, @IDinTheCloud, @mgd) to my original post on Identity Oracles, so would like to explicitly address that in this post.
**
** How does the traditional “pure tech” Identity and/or Attribute Provider operate and what if any are the constraints placed upon it?

From a technical interaction perspective, you have:

  1. Person presents to the Relying Party some token that has binds them to a unique identifier
  2. Relying party uses that unique identifier to call out to the Identity/Attribute Provider to retrieve attributes of the Person
  3. The Identity/Attribute Provider interacts with Authoritative Sources of information about the Person and returns the requested information to the Relying Party

Now let us look at this from a non-technical interaction perspective:

  • A contractual relationship exists between the Authoritative Sources and the Identity/Attribute Provider
  • A contractual relationship exists between the Identity/Attribute Provider and the Relying Party
  • A contractual relationship exists between the Person and the Relying Party
  • NO contractual relationship exists between the Person and Identity/Attribute Provider

Privacy Implications

  • The Relying Party typically click-wraps its privacy and information release in its interactions with the Person
  • The identity/attribute provider, as a business entity which needs to make money, is dependent on Relying Parties for its revenue stream
  • The identity/attribute provider, as the entity in the middle, has visibility into the transactions that are conducted by the Person and has significant financial pressure on it to monetize that information by selling it to third parties (or even to the Relying Party). For more information on this extremely sophisticated and lucrative market in private information, please read the recent series of investigative articles from the Wall Street Journal.
  • Given the lack of a contractual relationship between the Person and the Identity/Claims provider, the person has no visibility or little to no control over how this transactional information, which can be used to build a very detailed profile of the person, is used.

How does an Identity Oracle operate and what if any are the constraints placed upon it?

From a technical interaction perspective, you have:

  1. Person establishes a relationship with the Identity Oracle, which verifies their identity and potentially other information about them via its relationship to Authoritative Sources. The Identity Oracle provides the person with token(s) that allow the person to vouch for their relationship with the Identity Oracle in different contexts (Potentially everything from a Smart Card when you need very high assurances of identity to some token that asserts something about the person without revealing who they are)
  2. When the Person needs to conduct a transaction with the Relying Party, he presents the appropriate token needed which establishes their relationship to the Identity Oracle
  3. The Relying Party asks the Identity Oracle “Am I allowed to offer service X to the Person with a token Y from You under condition Z?”. The Identity Oracle answers “Yes or No”

Now let us look at this from a non-technical interaction perspective:

  • A contractual relationship exists between the Authoritative Sources and the Identity Oracle
  • A contractual relationship exists between the Identity Oracle and the Relying Party
  • A contractual relationship exists between the Person and the Relying Party
  • A contractual relationship exists between the Person and Identity Oracle

Privacy Implications

  • The Relying Party typically click-wraps its privacy and information release in its interactions with the Person but in many cases does not need to collect Privacy Sensitive information from the Person
  • The Relying Party can potentially outsource some functions as well as transfer liability for incorrect responses to the Identity Oracle
  • The Identity Oracle, as a business entity which needs to make money, has multiple revenue streams including the Relying Party as well as the Person, not to mention value added services it can offer to the Person
  • The Identity Oracle, as the entity in the middle, has visibility into the transactions that are conducted by the Person BUT is constrained by its contractual relationship with the Person to protect both the transactional information it has visibility into, as well as provide only meta-data about the private information it knows about the Person to Relying Parties

Some of the critical points that bears emphasizing with the Identity Oracle concept are:

  • Privacy protection of both PII information as well as transactional information with visibility and control by the Person
  • Allocation of responsibility and liability across Relying Parties, Identity Oracles and Persons.
  • Ability to conduct transactions that require very high assurances of identity to completely anonymous
  • Ability to conduct transactions across multiple modalities including in-person, internet/web, mobile devices and more
  • Ability to leverage existing technologies such as SAML, XACML, Smart Cards, OTPs and more

I hope that this blog post has been helpful in articulating the differences between a traditional identity/attribute provider and the identity oracle, and provides a case for the community to focus more on defining and articulating the contractual and business process aspects of the relationships of the parties involved, while simultaneously working on the supporting technology.



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.

Topic(s):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post.
Meet me over on Mastodon to join the conversation!

I am a public interest technologist. I help organizations and leaders make digital services secure and trustworthy.
Learn more »