Identity and The API Economy

This is a Guest post by Craig Burton who writes at http://www.craigburton.com/. He was also a special guest at the API Strategy Conference in San Francisco in October.

I recently attended and participated in the API Strategy and Practice conference in San Fransisco OCT 23-25. This was an exceptional conference and I met a lot of new people and learned many new things.

The panel I took part in is a panel discussion concerning  the API Economy. It was too short of a time slot do go very deep into the subject, but the moderator—Brian Proffitt—did a great job and the questions were interesting and relevant.

In retrospect, there was something curious missing from all of the presentations and conversations at the conference—the lack of discussion about the role of identity access management and APIs. It is clear that the API community doesn’t get that API ubiquity is an identity problem as much as it is an API design and maintenance problem.

Making Some Distinctions

To understand the connection, some definitions are in order. Identity management is complicated. The lingo is complicated. Understanding the lexicon used is the only way to really get a handles on this stuff works. The distinctions here are not exhaustive, but should be enough make my point. As a reminder, I am not insisting that anyone adopt these definitions and canonical and disregard the definitions that might be in place already, but to be rigorous in explaining the relationship between Identity and The API Economy, it is essential that a baseline ontology be established and used for discussion.

Kim Cameron’s famous blog provides great information about definitions and functions surrounding IdM. Pay special attention to the Laws of Identity.

I love the sequence he provides explaining the definitions of IdM basics.

There are a number of definitions pertaining to subjects, persons and identity itself:

Identity:  The fact of being what a person or a thing is, and the characteristics determining this.

This definition of identity is quite different from the definition that conflates identity and “identifier” (e.g. kim@foo.bar being called an identity).  Without clearing up this confusion, nothing can be understood.   Claims are the way of communicating what a person or thing is – different from being that person or thing.  An identifier is one possible claim content.

We also distinguish between a “natural person”, a “person”, and a “persona”, taking into account input from the legal and policy community:

Natural person:  A human being…

Person:  an entity recognized by the legal system.  In the context of eID, a person who can be digitally identified.

Persona:  A character deliberately assumed by a natural person

A “subject” is much broader, including things like services:

Subject:  The consumer of a digital service (a digital representation of a natural or juristic person, persona, group, organization, software service or device) described through claims.

And what about user?

User:  a natural person who is represented by a subject.

The entities that depend on identity are called relying parties:

Relying party:  An individual, organization or service that depends on claims issued by a claims provider about a subject to control access to and personalization of a service.

Service:  A digital entity comprising software, hardware and/or communications channels that interacts with subjects.

The other section that needs to be included here is Kim’s distinctions about claims. Read this carefully.

Let’s start with the series of definitions pertaining to claims.  It is key to the document that claims are assertions by one subject about another subject that are “in doubt”.  This is a fundamental notion since it leads to an understanding that one of the basic services of a multi-party model must be ”Claims Approval”.  The simple assumption by systems that assertions are true - in other words the failure to factor out “approval” as a separate service – has lead to conflation and insularity in earlier systems.

Claim:  an assertion made by one subject about itself or another subject that a relying party considers to be “in doubt” until it passes “Claims Approval”

Claims Approval: The process of evaluating a set of claims associated with a security presentation to produce claims trusted in a specific environment so it can used for automated decision making and/or mapped to an application specific identifier.

Claims Selector:  A software component that gives the user control over the production and release of sets of claims issued by claims providers.

Security Token:  A set of claims.

The concept of claims provider is presented in relation to “registration” of subjects.  Then claims are divided into two broad categories:  primordial and substantive…

Registration:  The process through which a primordial claim is associated with a subject so that a claims provider can subsequently issue a set of claims about that subject.

Claims Provider:  An individual, organization or service that:

Registers subjects and associates them with primordial claims, with the goal of subsequently exchanging their primordial claims for a set of substantive claims about the subject that can be presented at a relying party; or

Interprets one set of substantive claims and produces a second set (this specialization of a claims provider is called a claims transformer).  A claims set produced by a claims provider is not a primordial claim.

Claims Transformer:  A claims provider that produces one set of substantive claims from another set.

To understand this better let’s look at what we mean by  “primordial” and “substantive” claims.  The word ”primordial” may seem a strange at first, but its use will be seen to be rewardingly precise:  Constituting the beginning or starting point, from which something else is derived or developed, or on which something else depends. (OED) .

As will become clear, the claims-based model works through the use of “Claims Providers”.  In the most basic case, subjects prove to a claims provider that they are an entity it has registered, and then the claims provider makes ”substantive” claims about them.  The subject proves that it is the registered entity by using a “primordial” claim – one which is thus the beginning or starting point, and from which the provider’s substantive claims are derived.  So our definitions are the following:

Primordial Claim: A proof – based on secret(s) and/or biometrics – that only a single subject is able to present to a specific claims provider for the purpose of being recognized and obtaining a set of substantive claims.

Substantive claim:  A claim produced by a claims provider – as opposed to a primordial claim.

Passwords and secret keys are therefore examples of “primordial” claims, whereas SAML tokens and X.509 certificates (with DNs and the like) are examples of substantive claims.

Some will say, “Why don’t you just use the word ’credential’”?   The answer is simple.  We avoided “credential” precisely because people use it to mean both the primordial claim (e.g. a secret key) and the substantive claim (e.g. a certificate or signed statement).   This conflation makes it unsuitable for expressing the distinction between primordial and substantive, and this distinction is essential to properly factoring the services in the model.

Systems that manage Identity are referred to as Identity and Access Management (IAM) or just Identity Management (IdM)IdM components are divided into processes distinguished as Authentication and Authorization (AuthN/AuthZ).

Authentication

Authentication is the process of confirming the veracity of a specific attribute of a subject. There a “factors” of authentication often referred to as “multi-factor authentication”. The ways in which a subject can be authenticated is by something the subject has, something the subject knows, and something the subject is or does. Note that authentication is not just about people, but other subject—like and app or a piece of code that represents a machine or a device or a service. The most common factor used in AuthN is a subject’s name. But any number of factors can be used of any factor type.

Authorization

Authorization is a process distinct from authentication. Authentication is the process of a subject being verified that “it is who it says it is”.  Authorization is the process of verifying that it is permitted to “do what it is trying to do.” This distinction a little subtle, but suffice to say that authorization has to presuppose authentication and so they are separate processes.

Due to so many breaches to IdM systems in recent months, it is becoming more and more popular to require a “two factor” authorization process. We should expect that multi-factory authorization will become more and more a part of our lives in the future. I don’t want to get side tracked on multi-factor IdM so you can read Dave Kearns blog post for a good little primer and some links.

So a summary of AuthN/AuthZ is the processes that prove the validity of a subject’s claims perhaps a name and password to a particular system.

The Problem with AuthN/AuthZ

Nobody really needs to explain the problem in too much detail because everybody that uses the internet experiences the problem every day in excruciating detail.

The problem that every system, every service and every device have their own processes for AuthN/AuthZ. In other words, everything has its own name and password. We are drowning in what I call “name and password fatigue.”

The panacea for resolving name and password fatigue is finding solution for one name and password to provide secure AuthN/AuthZ to all system. This solution is referred to as Single Sign On (SSO). With SSO, all entities can properly and securely have access to information and resources without having to provide new credentials.

Some say we are close to reaching the panacea of a usable SSO environment.

Ha.

You wish.

The advent of mobile computing, cloud computing and social computing, coupled with the burgeoning API Economy just compounds the problem to unbelievable heights of complexity and difficulty. Don’t get me wrong, there are cool systems that have made tremendous strides towards SSO, there is just so much more to do.

The Cambrian Explosion of Everything

What is going on is so astounding Peter Van Auwera calls it the Cambrian Explosion of Everything.

Peter said:

The Cambrian explosion was the relatively rapid appearance of most major animal life forms, accompanied by major diversification of organisms. Before, most organisms were simple, composed of individual cells occasionally organized into colonies. Over the following 70 or 80 million years the rate of evolution accelerated by an order of magnitude and the diversity of life began to resemble that of today. (Adapted from Wikipedia )

He goes on to write that we are experiencing a similar explosion on the internet of everything. The next set of numbers will show you that Peter is exactly right.

My good friend Cheryl Snapp wrote an article in Forbes recently that had some incredible facts about Mobile devices in it. The article is mostly about mobile marketing—which is not my focus—but some of the research facts will help prove my point.

  1. There are 6.8 billion people on the planet at present. 4 billion own mobile phones. (But only 3.5 million use a toothbrush. Oy!) Source: 60SecondMarketer.com.
  2. As noted 91 percent of adults have their smartphones within arm’s reach. And that was as of 2007. I would wager the sum is closer to 100 percent now. (Source: Morgan Stanley)
  3. Twenty five percent of Americans use only mobile devices to access the Internet.  (Source: GoMoNews.com)
  4. There are 5x as many cellphones in the world as PCs. (Source: ImpigoMobile)
  5. 82 percent of U.S. adults own a cellphone. (Source: Pew Reports 2010)
  6. There are 271 million mobile subscribers in the U.S. alone.

And what about growth? Gartner recently published these numbers.

World Wide Devices Shipments by Segment (Thousands of Units)

Device Type 2012 2013 2014
PC (Desk-based and Notebook 341,273 305,178 289,239
Ultramobile 9,787 20,301 39,824
Tablet 120,203 201,825 276,178
Mobile Phone 1,746,177 1,821,193 1,901,188
Total 2,217,440 2,348,497 2,506,429

 

That’s right, 2.4 billion devices in 2013 and 2.5 billion in 2014.

It gets better (or worse depending how you view it), Gartner also predicts that there will be over 81 billion apps downloaded in 2013.

I could give you even more numbers about social computing and cloud computing that make this phenomena even crazier, but I think you get my point.

It’s an Identity Problem

I will make one more bold statement. I believe we are headed to a point where:

Everyone and everything will be API Enabled.

source: Craig Burton

Consider the implications. Billions and billions of things and people will need to be able to properly, securely and quickly AuthN/AuthZ to each other at any time with as few names and passwords as possible. At the same time, every entity—billions and billions—must have unique and secure names and passwords. Tough problem.

As an industry, we are struggling to build systems that let people properly, securely and quickly login to a few hundred systems. We have our work cut out for us. It seems as if solving the password fatigue problem is unsolvable.

Something happened 70 million years ago to trigger the Cambrian Era into existence. We don’t know what it was. Something is happening now to trigger the solution to the Cambrian Explosion of Everything— it is the API Economy itself.

Solving the problem requires the ability for machines to help us. Machines need programs and APIs to allow the solution to the problem to be automated. The API Economy provides the framework for an automated solution to come into existence.

Summary

In a digital world where there are billions and billions of entities that require proper and secure identity management, we will need to build systems, services and apps that help us automate the creation, evolution and maintenance of the solution.

There is no better time for The API Economy to get a foot-hold and evolve into a capable framework that will let us solve the Identity problem soon.