In the initial years of the world wide web, much was innovated as it was needed — while the fundamentals were open and commonly agreed upon, the systems that used these fundamentals often were not. Innovation led to unique solutions, which led to the development of proprietary systems and approaches.

However as time marched on, the systems that utilized the world wide web moved more and more towards its open source roots. With each new innovation came ample documentation, and the age of proprietary communication protocols and solutions was soon replaced by the age of open standards.

Due to this near ubiquity of open standards, developers tend to think of them as “basic” implementations — it’s awfully tempting to many devs, for instance, to opt for a proprietary security protocol tested and developed independent of an older, open standard.

The truth is that adopting open standards and building systems within their confines can lead to better functionality, improved interoperability, and most importantly, increased longevity.

What are Open Standards?

In the context of web APIs, open standards are specifications for web communication protocols that are created, maintained, and distributed by the general international development community. These standards are commonly agreed upon, and as they evolve, are often incorporated into newer standards and systems.

That really only scratches the surface, though — open standards are, by their nature of being open, somewhat hard to pin down. While there are a few specific definitions, the interpretations of these definitions can result in wildly varying applications. Many open standards providers have their own licensing stipulations, thoughts on what constitutes “open standards”, and so forth.

The best we can do, then, is to define the common hallmarks of an Open Standard. While not every Open Standard will fall into every aspect listed below, those that do not are deviations from the standard, not standard themselves.

An Open Standard is (generally):

• Controlled by a standard making body or group of organizations;
• Accepted as a valid implementation by the majority of the industry;
• Available to anyone for free implementation, error checking, and derivative development.

While these standards are indeed free to adopt, they often come with specific licensing or requirements for implementation. As a turn of phrase, these licenses are often referred to as “copyleft” (a play on copyright). An example license is the Creative Commons CC BY 4.0 License, which allows for free use, sharing, and adaptation of the standard, as long as attribution is included in the form of a link where the standard is used or implemented (which is typically done by including a link in the solution documentation).

5 Examples of Open Standards in the API Space

Now that we know what an Open Standard is, let’s look at some real-world examples.

OAuth

OAuth, which is short for Open Authorization, was initially released in 2006 as an authentication method for the twitter API. Designed by Twitter architect Blaine Cook, OAuth was designed to be an open standard for API access delegation. OAuth is now used by Google, Facebook, Microsoft, and many other enterprise providers.

OAuth provides this delegation of access by allowing third-party clients to receive tokens from an authorization server, giving them delegated access to other sites who accept the validity and the authority of the authorization server.

Of note is the fact that OAuth provides not only a method of delegated access, it does so by reducing the sharing of passwords between users and third parties. Additionally, OAuth includes a mechanism for authorization revocation, making it a very secure system indeed.

Open ID/OpenID Connect

OpenID, despite the similar sounding name, is very distinct from OAuth. Designed and promoted by the OpenID Foundation, OpenID is functionally a federation methodology by which cooperative sites (called Relying Parties in the documentation nomenclature) can agree on a third party service for identification.

What this functionally means is that the user doesn’t have provide a separate identity and password to each service, as they can access the sites and services with a single token. Google, Amazon, LiveJournal, and even Myspace have used or continue to use OpenID systems as their principal methods of identification and authorization.

SCIM

SCIM, or the System for Cross-domain Identity Management, is a business-oriented open standard used to manage user identity in IT systems. It was released in 2011 by the Open Web Foundation, and then transferred to the Internet Engineering Task Force (IETF) later that year. The current standard is SCIM 2.0, which was released as an IETF RFC (Request for Comment) in 2015.

An example use case would be hiring and firing employees. Using the SCIM system, employees can be automatically added or removed from the employee directory and all related third party systems, such as those in Office 365 or Google Apps.

SCIM isn’t just for adding and removing identity profiles either, as it can also be used to share data about the identity attributes, group membership, contact information, and other related data. The most important aspect to all of this is that this data is shareable in a format and system that is maintained across multiple IT domains.

U2F

U2F is a universal open authentication standard that utilizes two-factor authentication on USB or Near Field Communication (NFC) devices. In 2012, the FIDO (Fast Identity Online) Alliance was formed with PayPal, Nok Nok Labs, Lenovo, Validity Sensors, Infineon, and Agnitio as the founding companies. They immediately began work on a non-password dependent method of authentication.

At the same time, Google, Yubico, and NXP continued work first started in 2011 towards the same end. In 2013, the two groups merged their efforts into the FIDO Alliance, publicly launching the open protocol later that year.

U2F is used as an authentication method for Dropbox, GitHub, Chrome, Bitbucket, Opera, and more. Microsoft is actively working on incorporating FIDO 2.0 into Windows 10, though there are no plans to incorporate the next step, U2F, into the stack.

JSON

JSON, or JavaScript Object Notation, is an open-standard format for data that is human-readable, and a main driver in the API space. JSON was initially specified by Douglas Crockford in the early 2000’s, with its formal definition occurring in 2013 as part of RFC 7159, and the allowed syntax being stated in Ecma International (European Computer Manufacturers Association) RFC ECMA–404.

The format is specifically designed to transmit data objects in attribute-value pairs, and is the most common data format used in asynchronous browser/server communications. JSON has risen meteorically in popularity, replacing XML in everything from web development to plugin configuration specification for online games.

Benefits of Adopting Open Standards

As you can plainly see, open standards make up a huge share of online methodologies. That’s why it’s so surprising, then, that the power of incorporating open standards is often ignored for the sake of “reinventing the wheel” and developing proprietary solutions for authentication, data formats, and more.

There are a good many reasons a company should adopt open standards; at the very least, every organization considering the development of a proprietary solution should consider the following benefits before pushing forward.

Improved Security

What makes for a secure lock? Would you prefer a lock that has been tested, manipulated, and evolved from those failures in security, or would you prefer a lock that is proprietary with no data shared and no testing allowed? This is what makes open standards so powerful. Since the standards are, by design, open for testing and inspection, problems are found more quickly and immediately dealt with by a community of experts.

By allowing for this constant testing and iteration, open standards entail more secure code, and thus have the effect of granting better identity control and more secure services. Additionally, in terms of longevity, this also establishes a much more professional ecosystem of offering, improving both the appearance of an integrator and the quality of the product in which the open standard is integrated.

Cost

Because an open standard by its nature is free for implementation, using open standards has a huge cost benefit not only in the short run, but in the long run. Many closed, proprietary standards require constant licensing fees over time and per groups of users or bulk call amounts.

This means less cost in the immediate for developing proprietary solutions, less cost in the intermediate due to lower overhead for maintenance and bug fixing, and less cost in the long term as the open standard will always be under the same free license.

Interoperability

open standards are designed to accept each other, or at the very least play nice. Using proprietary systems requires that you at some point create a translation layer so that you can operate with other services and systems. Skipping this step, and designing from the ground up to use commonly accepted standards can result in massive synergy between disparate systems.

Timelessness

There’s an inclination for developers to work within the “flavor of the month”, adopting hot new solutions with bright, popping web 2.0 (or 3.0?) names. The fact of the matter, though, is that APIs and IT systems should be developed with an eye towards longevity, not just marketing.

Open standards in any industry leads to longevity. For instance, during a recent talk from Henrik Segesten at the 2016 Platform Summit, Segesten tracked the rise and fall of 30 years worth of protocols and data formats. He found that open communication protocol standards lasted longer and became more widely adopted than proprietary solutions.

Caveats: 3 Tips to Keep in Mind

As with anything, though, there are some caveats. Failing to follow these basic tips can make all the benefits of open standards zero.

1. Update When Prompted

You need to update when prompted. This is vitally important. open standards means auditable, and with this auditing comes an exposure of vulnerabilities. While this leads to greater security in the long run, this also means that the need to stay updated and modern is even more important than in proprietary systems.

If you fail to update your systems when a dependency or issue is exposed, you are leaving yourself just as exposed. Failure to update means you’re not just using vulnerable solutions, you’re using vulnerable solutions that hackers know are vulnerable – that’s a good way to paint a giant target on your back.

2. Read RFCs, Be Educated

Standards setting bodies are bureaucratic by nature, and as part of this, standards setting bodies often issue RFCs, or Request for Comments. Read them, and read them often. Understanding and engaging in the conversation as to the evolution of a standard not only helps turn the developer into a willing, beneficial participant, it also helps to guide the development of the standard into an even better direction.

3. Follow Licensing

There seems to be a misconception, especially in the enterprise space, that “open standard” means “open source”, and that “open source” means “free for all”.

This is not true. open standards may have their own sets of licenses for use, and these must be followed. This isn’t just a matter of feel-good or process – failing to follow the licenses included in open standards solutions can kill the industry by painting the bastardized solutions as vanilla implementations, discrediting the standards scene.

That’s not even to mention the fact that, often, this is a matter of law in some licenses, and can result in, at best, a judgement for copyright violation, and at worst, a massive lawsuit when your proprietary unlicensed variation on an open standard exposes millions of users to a flaw that was patched out in the actual vanilla implementation.

Conclusion

Simply put, using and actively participating in open standards just makes sense.

Economically speaking, adopting an open standard can result in decreased cost in the immediate, intermediate, and long-term. When it comes to security, open standards can result in a more secure, less vulnerable ecosystem.

Open standards adoption means better longevity. Consider some of the most popular pre-internet “internets”, especially those with closed ecosystems and dial-in modems. Most readers would be hard pressed to give a name or example of one of these proprietary internet services. The World Wide Web, the best example of an open standard the world has ever seen, is testament enough to the staying power of an open standard.