• Personal Identity in the Cloud – What’s a Programmer to Do?

    September 20, 2012 • Uncategorized • 2 Comments

    A forum I follow recently made note of a blog post from Craig Burton at KuppingerCole, a European leader in the areas of identity and access management, governance, risk management, and compliance. The post keyed off of the recent Apple iPhone 5 announcement, citing statistics from both Apple and Cisco that document the explosive growth in internet connected devices, and the anticipated tsunami of interconnections as we evolve into the “Internet of Things.”

    I have to admit, the statistics from the Apple announcement, especially when combined with the view from Cisco, definitely make one stop and think. But Craig Burton’s blog post has apocalyptic overtones that I don’t think are accurate.

    First, Apple’s original release of the iPhone was a watershed event that precipitated the rapid expansion of smartphone adoption. What drove this change was actually the AppStore, and the commerce model which it created. Suddenly smartphones were more than a curiosity, or the status symbol of the ever-connected executive (e.g., RIM/Blackberry.) Finally, these hand-held devices could entertain and do “real” work beyond just rich media messaging.

    Second, the ramp in adoption driven by this shift should not come as a surprise to anyone who’s been around technology for the past 20 years. Technology adoption has been accelerating since 1900. To a great extent, that acceleration powers itself since new tech spreads new ideas (and products) that much faster. That growth in turn creates new transaction opportunities that require some degree of personal (or entity) identification and verification.

    When Craig Burton refers to “20+ billion APIs all needing distinct identities”, what I believe he is actually referring to is interconnections and not discrete APIs. Each of these interconnections will certainly require one or more APIs for access and data transfer, and will also require identification and verification of any interacting entities or individuals. Universities and tech schools might be excited by the prospect of teaching all those APIs, but it’s highly unlikely that each of those interconnections will organically promote its own unique API. Suggesting that the existing federated naming protocols and infrastructure is labor intensive and will collapse and fail reminds me of the plumbing in Terry Gilliam’s movie, “Brazil.” Pity the poor administrator (or programmer) who tries to correct a simple mistake and in turn finds themselves an enemy of the state!

    Managing identity – entity or personal – within the Cloud certainly has some unique  challenges. Fortunately, there are substantial communities such as the NSTIC Identity Ecosystem and projectVRM that are focused on defining standards for creating, validating, managing, and transacting trusted identities as well as looking at the broader issue of how individuals can control and assert their identity and preferences when engaging products, services, and vendors within this expanding internet of things. Multiple solutions will likely be proposed, developed, will co-exist, and eventually consolidate based on the collective wisdom and adoption of the cloud community. That community – or ecosystem – is really the key.

    Without a doubt, there are some interesting times ahead, especially in the area of identity management. In the meantime, I think another interesting viewpoint on how the API Economy in the Cloud will develop in a more organic way is outlined by Michael Vizard at Slashdot.

    2 Responses to Personal Identity in the Cloud – What’s a Programmer to Do?

    1. Pingback: It Takes a Community | Craig Burton

    2. November 29, 2012 at 3:11 pm

      Craig and I agree about more than we disagree about. Specifically, we agree that the Internet of Things is growing exponentially, and that identity is a critical aspect of IoT evolution. And the explosion in device types and identities means a potential corresponding explosion of API interfaces.

      I think the disconnect is in how we are defining the acronym/term “API”, and how we believe the challenge of API multiplicity should best be addressed. That’s definitely a discussion worth continuing, but probably not on this blog.

    Leave a Reply to Tom Wilson Cancel reply

    Your email address will not be published. Required fields are marked *

    Current ye@r *