Zero Trust Identity: Go From "Identity-As-A-Service" To "IAM-As-An-API"

I just love the theme of our upcoming Forrester Security Forum (Las Vegas in May, and Paris in June -- check out Laura Koetzle's definitive blog post). Leapfrog Your Global Competition. Rethink Security; Run At The Threat. There's never been a better time to take a deep breath and rethink how security can contribute to business savvy and agility. The "Zero Trust Identity" report I'd telegraphed in my previous post on API access control is now out, and it's consonant with this theme. I found that if enterprises want to be nimble and secure in getting value out of mobile, cloud, and consumerization trends, they're going to have to get over some bad "unextended enterprise" habits, such as tight coupling to authentication functions.

App dev trends around the open Web (for which see some excellent research here) are throwing a lifeline to IAM. The trick is to think in resource-centric, unified, and Internet-scale terms. So the nutshell answer to "How should we deliver our identity provisioning, authentication, and authorization functions now?" is "Expose them through Web-style APIs and make our business apps into API clients!" This approach is a key enabler if you want to partner with other organizations, use SaaS apps, and facilitate mobile usage with the same security and auditability you've come to expect of your own infrastructure.

If you've got thoughts on this notion, I hope you'll reach out for a one-on-one chat at the Forum, and/or drop me a note in the comments or on Twitter. You can track and contribute to the Forum using the #FSF12 (Las Vegas) and #SFE12 (Paris) hashtags.


APIs? Or Standards? Or what?

@JamieXML said: Forrester's @xmlgrrl continues to move away from #standards into APIs: "Zero Trust Identity": HT @BinaryBlogger ...

Eve asked what I mean. Well, your blurb is generally is about APIs as a reliable interoperability method. I'm all ears. How can we define "standard" APIs? (I realize there are some fine, relevant $500 Forrester reports that I have not read. I work for a global nonprofit, so apologies there.)

Here, I don't think the world "standard" means "data structure." I think it has to mean "reliable, testable and stable data structure." The point of having one is: I can do business with some stranger, who claims to be compliant with Foo Standard, just by forming compliant messages myself. Voila! Global commerce!

BUT, to be reliable, the thing (API, data structure specification, whatever) needs to be:

-- palpably open-enough, and vendor-neutral enough, that vendor lock-in or platform lock-in demonstrably are not high risks.
-- owned and versioned archivally, so that it doesn't suddenly go away, or suddenly change to conform to some controlling party's strategy choices.
-- testable.
-- a stable, widely-trustable final publication.
-- maintained by neutrals who are stable and widely-trustable too.

In other words, for big networks of government or commerce to rely on a data practice heavily, that practice must have a bunch of governance and provenance attributes that we call ... "being an open standard." This explains the criteria of the WTO (TBTT), the US OMB (A119), the EU (98/34), etc. Just setting up a dot-org, or having BigCo publish its APIs, or coding to a cool new non-standards-track unapproved draft, isn't enough, when a data practice wants to put on its big-boy pants, and voluntarily be used by the whole world or by global institutions.

As you know well, from experience, a lot of good tech ideas, while cool, just aren't willing to do the work necessary to graduate to that level. That's why there are so MANY dot.orgs, unapproved RFCs, and CoolOpenMicroThingie initiatives. Crack them open, and 9 out of 10 are one or two companies, dictating the whole deal. Governments are painfully, quietly aware of this. Thus the regulatory preference for standards.

So: APIs are important. How do we get past "here's my API, trust me?"

Your view raises a cool question: from where can we get highly reliable, juried neutral assurances about APIs? I'm not saying it's impossible -- I have high hopes for the OpenStack Foundation, for example -- but history is not littered with successes, here.

In our field, when experts actually want to create something of lasting shared value, they generally put on those big-boy pants, and deal with all the annoying IPR and compromise hassles of Real Open Standards Orgs. That's why the XML and SAML you helped write a decade ago are still around, and still usable -- by systems that require long-term capital investments and long-term returns.

We're all confident that Tim Berners-Lee and his colleagues aren't going to go in there and secretly fiddle with the published HTML 4.01 spec. We repose trust in them, in the form of millions (millions!) of global implementers who rely on the spec -- even though there are zillions of €£$¥ (zillions!) aimed at HTML -- who probably would love to change bits and pieces of it, to suit various product quirks. (Look at the HTML5 debates.) And if HTML was managed by some new volunteer-run, or dominated by a single company, well, they might get away with it, too.

So: how do we get to that level with APIs?

Regards Jamie @JamieXML

Standards can include more than data formats

Hi Jamie-- Thanks for your always-thoughtful comments!

I'd say standards can be around lots of things, including even user interface elements! Critically, in the realm of machine-to-machine communications, standards may include protocols -- typically orchestrated request and response messages (whose format is also standardized). All web services standards have elements of protocol as well as data structure in them, and the new crop of "APIs" is, I'd argue, much closer to protocols in spirit than to the application programming interfaces of old, because they're platform and computer-language independent.

The http-json-resource spec is an example of a proposed standard that's pretty much nothing but the protocol piece, except for assuming messages that use the JSON (JavaScript Object Notation) format: It suggests a way to standardize the underpinnings of Web-friendly CRUD (create/read/update/delete) APIs so that the world can design and implement and deploy more of them, faster, in a more regularized way.

De facto and de jure APIs can be and are being standardized all over the place, in much the same way as other types of standards. XML was standardized by W3C, where some device APIs are being standardized now. OASIS was the home of SAML standardization -- and you can see SAML as a standard set of APIs, though it's not optimized for use on the open Web the way some others are. (SAML assertions define the token format; SAML protocols/profiles define the exchange of messages between endpoints.) The Simple Cloud Identity Management API was incubated in lightweight (de facto) fashion, but is now being taken up for consideration at IETF using its normal (de jure) processes.

So, in short, I think there's nothing stopping us from getting where you would like to go with APIs, and in many cases, it's happening already.

How to create trust

You are absolutely right - there needs to be a change in how these issues are approached. As the landscape changes towards SaaS and IDaaS we need to create models for inter-federation of these identities and create the right frameworks, standards and specifications to support these. I think this is already happening in many ways even within the existing models of oAuth/etc.

What I think it is critical (and something we are definitely seeing change in the market) is a recognition of the source of this trust. Its not enough just to share an identity - we have to have a confidence or assurance in that identity. The NSTIC is pushing ahead on this front in the States but we need to start agreeing on common sources of these validations to give the IDaaS/SaaS infrastructure real value. Proving your real identity is critical in this new model.

Establishing trust: tricky at Internet scale

James-- Agreed on these points! Actually, my first research report touched on this: Outsourcing Identity Assurance Will Be A Realistic Option Within Three Years. That was about a year ago. Signs of life since include things like Verizon's certification as an IdP at level of assurance 3.