All posts in Credentials

Credentials: A Retrospective of Mild Successes and Dramatic Failures

Over the past 20 years, various organizations have tried to “solve” problems related to identity and credentialing on the Web and have been met with varying degrees of mild success, but mostly failure. Understanding what worked and what did not is necessary if we’re going to make progress on identity and credentialing on the Web.

The word identity means different things to different people and is often discussed as a problem waiting to be solved on the Web. In the physical world, we have many identities. We have an identity for work life and home life. We have an identity that we use when we talk with our friends and one that we use when we talk with our families. The concept of identity is as nuanced as it is broad.

There are aspects of our identities that have very little consequence to others, such as whether we have dark brown hair or black hair. There are also aspects of our identities that are vital for proving that we should be able to perform certain tasks, like a drivers license or nursing license. Then there are aspects of our identities that are important for social reasons, such as the rapport that we build with our friends over multiple decades.

Many aspects of our identity are often expressed via credentials, which can be seen as verifiable statements made by one person or organization about another. There have been multiple attempts at formalizing credentials on the Web; each one of them have been met with varying degrees of mild success, but mostly failure. This blog post explores the development goals and system capabilities that would lead to a healthy credentialing ecosystem and why previous attempts to achieve these goals have been met with limited success.

Credentialing Ecosystem Goals

A healthy credentialing ecosystem should have a number of qualities:

  • Credentials should be interoperable and portable. Credentials should be used by as broad of a range of organizations as possible. The recipient of a credential should be able to store, manage, and share credentials throughout their lifetime with relative ease.
  • The ecosystem should scale to the 3 billion people using the Web today and then to the 6 billion people that will be using the Web by the year 2020.
  • The process of exchanging a credential should be privacy enhancing and recipient controlled such that the system protects the privacy of the individual or organization using the credential by placing the recipient in control of who is allowed to access their credential.
  • Implementing systems that issue and consume credentials should be easy for Web developers in order to lower barriers to entry and increase the amount of software solutions in the ecosystem.
  • Creating systems that are accessible should be a fundamental design criteria, as 10% of the world’s population have disabilities and the solution should be usable by as many people as possible.
  • The solution should follow a number of core Web principles such as being patent and royalty-free, adhering to Web architecture fundamentals, supporting network and device independence, and being machine-readable where possible to enable automation and engagement of non-human actors.

Credentialing Capabilities

A solution for a healthy credential ecosystem should have the following capabilities:

  • Extensible Data Model – A data model that supports an entity making an unbounded set of claims about another entity. This enables a very broad applicability of credentials to different use cases and market verticals.
  • Choice of Syntax – A data model that is capable of being expressed in a variety of data syntaxes. This increases interoperability between disparate credentialing systems and increases the long-term viability of the technology.
  • Decentralized Vocabularies – A formal mechanism of expressing new types of claims without centralized coordination. This promotes a high degree of parallel adoption and innovation.
  • Web-based PKI – A digital signature mechanism that does not require out-of-band information to verify the authenticity of claims; instead it should enable public keys to be automatically fetched via the Web during verification. It should not render the signed data opaque because opaque data is harder to learn from, program to, and debug. This makes the digital signature mechanism easier to use for developers and system integrators.
  • Choice of Storage – A protocol for storing a credential at an arbitrary identity provider after it has been issued by an arbitrary issuer. This helps create a level playing field for all actors in the ecosystem.
  • App Integration – A protocol for managing credentials by a recipient using arbitrary 3rd party applications. This promotes a healthy application ecosystem for managing credentials.
  • Privacy-enhanced Sharing – A protocol that enables the recipient to share their credentials without revealing the intended destination to their identity provider. This enhances privacy.
  • Credential Portability – A protocol for migrating from one identity provider to another without the need to reissue each credential. This promotes a healthy identity provider ecosystem.
  • Credential Revocation – A protocol for revocation of a previously issued credential by the credential issuer. This enables issuers to ensure that the credentials they have issued accurately represent their claims.

A Foreword on the Analysis

There are a number of existing identity, credentialing, and general authentication solutions that have been deployed in the past and have seen success according to the design goals of the particular solution. The design goals and capabilities listed in the previous sections do not always align with the design goals and capabilities of the systems that have been analyzed below. It is fair to say that some of the analysis below is “unfair” as some of the systems are being judged against criteria that they were not meant to address. The reason these solutions have been included below are because 1) they come up in conversation as potential solutions, and/or 2) they have been successful in meeting some of the criteria listed above, and/or 3) they have failed in important ways that we need to learn from to ensure that a new initiative doesn’t make the same mistakes.

With that said, let’s get on with the analysis.

SAML

The grandparent of these identity initiatives is SAML, an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

Capability Rating Summary
Extensible Data Model Problematic XML-based data model. Extensible, but extensibility is rarely used leading to very limited claim types.
Choice of Syntax Poor Only XML is supported.
Decentralized Vocabularies Problematic The use of simple key-value pairs created the possibility of name clashes, limiting decentralized innovation and adoption.
Web-based PKI Problematic Service Providers had to explicitly trust Identity Providers leading to scalability issues.
Choice of Storage Poor Recipients can only have credentials issued and stored via a single identity provider.
App Integration Poor A recipient could only manage their credentials via their identity provider interface.
Privacy-enhanced Sharing Poor Identity providers cannot be prevented from knowing where recipients use their credentials.
Credential Portability Poor Credentials cannot be transferred from one identity provider to another.
Credential Revocation Problematic Credentials can only be issued and revoked by identity providers.

SAML has failed to gain traction outside the education and public service organization sectors and is rarely used as an option to log into non-enterprise websites. SAML isn’t a viable solution for the goals and capabilities listed above because 1) it is hobbled by older technologies such as XML and SOAP, 2) it has scalability issues due to the need to manually setup federations of identity and service providers, 3) it restricts the organizations that can issue valid credentials to identity providers, 4) it enables tracking and violates a number of privacy requirements listed above, and 5) it encourages centralization and super providers as more people use the system because of the administrative overhead of managing the identity and service provider federations as they grow.

Windows CardSpace / Infocard

Microsoft released CardSpace (code named InfoCard) in late 2006. CardSpace stored references to your digital identity, presenting them for selection as visual Information Cards. CardSpace provided a consistent interface designed to help you easily and securely use these identities in applications and websites.

Capability Rating Summary
Extensible Data Model Problematic Extensibility was possible (XML and URLs), but hard coded strings were used for parameter names.
Choice of Syntax Poor Only XML was supported.
Decentralized Vocabularies Problematic URLs were used for parameter values, but the solution was ultimately Windows-only.
Web-based PKI Good XML enveloping signatures with attached X509 certificates were used.
Choice of Storage Good Credentials were stored in an application controlled by the recipient.
App Integration Problematic Credentials were managed by a Windows application.
Privacy-enhanced Sharing Good Credential consumers requested credentials directly from the recipient.
Credential Portability Problematic Credentials could only live on Windows devices with no automatic cross-device synchronization capability (although manual export/import was supported).
Credential Revocation Good Security tokens are not granted for revoked credentials.

Windows CardSpace failed to gain traction and the project was canceled in 2011. The initiative has been replaced with U-Prove, a Microsoft Research project. CardSpace did get a number of things right, but ultimately failed because 1) it was largely a Microsoft-centric solution that required Windows and Active Directory 2) early adopters that initially backed the project did not feel as if there was a strong near-term demand for a solution and thus didn’t roll out products to support the standard, 3) it didn’t scale to mobile and was largely tied to the desktop, 4) it was a separate product requiring manual installation and not a feature of Internet Explorer, 5) while it supported verified claims through a trusted third party, very few applications surfaced that enabled that optional feature, and 6) it was partly based on the WS-* technology stack, which has been derided as “bloated, opaque, and insanely complex“.

Shibboleth

Shibboleth is a middleware initiative for an architecture and open-source implementation for identity management and federated identity-based authentication and authorization. It is based on SAML and thus has many of the same advantages and drawbacks.

Capability Rating Summary
Extensible Data Model Problematic XML-based data model. Extensible, but extensibility is rarely used leading to very limited claim types.
Choice of Syntax Poor Only XML is supported.
Decentralized Vocabularies Problematic The use of simple key-value pairs created the possibility of name clashes, limiting decentralized innovation and adoption.
Web-based PKI Problematic Service Providers had to explicitly trust Identity Providers leading to scalability issues.
Choice of Storage Poor Recipients can only have credentials issued and stored via a single identity provider.
App Integration Poor A recipient can only manage their credentials via their identity provider interface.
Privacy-enhanced Sharing Poor Identity providers cannot be prevented from knowing where recipients use their credentials.
Credential Portability Poor Credentials cannot be transferred from one identity provider to another.
Credential Revocation Problematic Credentials can only be issued and revoked by identity providers.

Shibboleth has failed to gain traction outside the research, education, and public service organization sectors and is rarely used as an option to log into non-enterprise websites. Shibboleth is not a viable solution for the goals and capabilities listed above because 1) it is hobbled by older technologies such as XML and SOAP, 2) it has scalability issues due to the need to manually setup federations of identity and service providers, 3) it restricts the organizations that can issue valid credentials to identity providers, 4) it enables tracking and violates a number of privacy requirements listed above, and 5) it encourages centralization and super providers as more people use the system because of the administrative overhead of managing the identity and service provider federations as they grow.

OAuth 2.0

While not an identity or credentialing solution, OAuth 2.0 often comes up as being in the same class of solution and has been used (by Facebook and OpenID Connect) to achieve an authentication/authorization solution. Introduced in 2006 and finalized as OAuth 2.0 in 2012, the latest version of the framework has wide deployment among Facebook, Google, and Microsoft but suffers from multiple non-interoperable implementations.

Capability Rating Summary
Extensible Data Model Poor Key-value pairs, which require centralized coordination to avoid conflicts.
Choice of Syntax Poor Only string-based key-value pairs are supported.
Decentralized Vocabularies Poor Key-value pairs, which require centralized coordination to avoid conflicts.
Web-based PKI N/A OAuth 2.0 is not designed to perform digital signatures.
Choice of Storage N/A OAuth 2.0 is not designed to express credentials.
App Integration N/A OAuth 2.0 is not designed to manage credentials.
Privacy-enhanced Sharing N/A OAuth 2.0 is not designed to request credentials.
Credential Portability N/A OAuth 2.0 is not designed to port credentials.
Credential Revocation Problematic OAuth 2.0 tokens timeout after a while, but operate as bearer tokens (if they are stolen, they can be used by other people for a non-trivial amount of time).

OAuth 2.0 was never designed to achieve the goals and capabilities listed at the beginning of this blog post, and so the comparison above isn’t very fair. That said, there are a number of reasons that OAuth 2.0 is not a good fit for the goals and required capabilities listed above: 1) it is often criticized as being problematic from a security standpoint, overly complex, and favoring large enterprise deployments, 2) it doesn’t have a data model that is flexible enough to model more than the most basic type of credentials, 3) it does not support digital signatures, and 4) it doesn’t solve the credentialing problem described above because it is designed for a completely different set of use cases: providing access to 3rd parties that want to perform certain operations on your account. While OAuth 2.0 is not a solution to the credentialing problem, it can be used as part of a credentialing solution, which is what OpenID Connect does.

OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

Capability Rating Summary
Extensible Data Model Problematic JSON is extensible, but needs a single centralized registry for terms or full URLs must be used.
Choice of Syntax Poor Only JSON is supported.
Decentralized Vocabularies Poor Extensions require a single centralized registry for terms or full URLs must be used.
Web-based PKI Poor URLs can be used for JWK key IDs, but the mechanism to do discovery isn’t specified in the specifications.
Choice of Storage Poor Credential information is not portable.
App Integration Problematic Recipients can only manage credentials via their identity provider.
Privacy-enhanced Sharing Poor Identity providers can track all logins.
Credential Portability Poor Credentials are not portable between identity providers.
Credential Revocation Problematic Distributed credentials can be revoked at any time, but are rarely used.

The OpenID initiative started in 2005. Today Google, Microsoft, Deutsche Telekom, and SalesForce use the OpenID Connect protocol to support federated login, but Facebook and Twitter do not. OpenID Connect has been fairly successful in creating a Web-scale single-sign on solution, but it fails to address the goals and required capabilities for the following reasons: 1) it depends heavily on centralized registries to define types of credentials, 2) credentials issued by 3rd parties and digital signatures are rarely used (there is no rich 3rd party credential ecosystem), 3) there is no protocol for transferring credentials from one provider to another, 4) it enables tracking and other privacy violations, and 5) it promotes centralization and super-providers due to a reliance on email-addresses-as-identifiers, ensuring that email super providers become the new credential super providers.

WebID+TLS

WebID+TLS, previously known as FOAF+SSL, is a decentralized and secure authentication protocol built on W3C standards around Linked Data and utilizing client-side x509 certificates and TLS to boostrap the identity discovery process.

Capability Rating Summary
Extensible Data Model Good WebID is based on RDF which is a provably extensible data model.
Choice of Syntax Good WebID is based on RDF and thus supports multiple syntaxes.
Decentralized Vocabularies Good All data is expressed using vocabularies, which can be created by anyone. Data merging is designed to happen automatically.
Web-based PKI Problematic All claims in a WebID are self-issued claims. No clear specification for 3rd party claims.
Choice of Storage Good WebIDs can be stored at the recipient’s preferred location
App Integration Problematic Possible, but no clear specification exists to do so.
Privacy-enhanced Sharing Problematic Identity Providers can track logins by default (unless a mixnet is used).
Credential Portability Problematic Self-issued credentials can be ported easily. If there were 3rd party credentials tied to WebID URL, those credentials would not be portable.
Credential Revocation Problematic Revocation is possible, but there is no clear specification for doing so.

WebID+TLS was first presented for the W3C Workshop on the Future of Social Networking in 2009, but has failed to gain any significant traction in the past six years. WebID+TLS is also problematic because 1) it depends on browser client-side certificate handling, which is a bad UI experience, 2) it depends on the KEYGEN HTML element in a non-trivial way, which is currently under discussion to be removed from certain browsers, and 3) it is not well specified how you achieve many of the credential goals and required capabilities listed in the beginning of this post.

Mozilla Persona

Persona was launched in 2011 and shares some of its goals with some similar authentication systems like OpenID or Facebook Connect, but it is different in several important ways: 1) It used email addresses as identifiers, 2) It was more focused on privacy, 3) It was intended to be fully integrated in the browser.

Capability Rating Summary
Extensible Data Model N/A Not a design requirement.
Choice of Syntax N/A Not a design requirement.
Decentralized Vocabularies N/A Not a design requirement.
Web-based PKI Problematic Public keys are discoverable but content is largely hidden.
Choice of Storage Poor Identity provider is tied to login domain.
App Integration N/A There are no credentials to manage.
Privacy-enhanced Sharing Good Logins are privacy-enhancing and not easily trackable.
Credential Portability Poor There are no credentials to port.
Credential Revocation N/A There are no credentials to revoke.

Persona is solely an authentication system and was not designed to support arbitrary credentials. Mozilla was hoping for widespread adoption of the protocol, but that did not occur because super providers like Google and Facebook had already developed their own competing login mechanisms. All full-time developers were pulled from the project in 2014.

Omitted Technologies

There are a number of technologies, such as U-Prove, the WebAppSec Login/Credentials API, and Mozilla’s Firefox Account API, that were not included in this analysis because they are still very early in the research and development phases. APIs like Facebook Connect and Login with Google were not included because they are not intended to be open standards.

Conclusion

There are a number of goals and required capabilities that need to be fulfilled in order to create a vibrant credentialing ecosystem. There have been various attempts at addressing subsets of the problems in the ecosystem and those solutions have been met with small successes and varied failures. There still is no widely deployed and adopted way of issuing, storing, managing, and transmitting credentials on the Web today and we do have quite a bit of insight into why the prior attempts at solving the general identity/credentialing problem have failed.

These findings lead to a simple question: Is it time to do something about Credentials on the Web?

The Case for Standardizing Credentials via W3C

Credentials solve a variety of real authentication problems on the Web today, we can implement them in a way that doesn’t threaten anonymity or privacy and avoid the mistakes made in previous attempts. The W3C is the right place to do this important work.

Over the past two years a growing number of organizations in education, finance, and healthcare have been gathering in W3C Community Groups around the concept of a standard format for credentials on the Web.

A credential is a qualification, achievement, quality, or piece of information about an entity’s background, typically used to indicate suitability. A credential could include information such as a name, home address, government ID, professional license, or university degree.

We use credentials when we show our shoppers card to get discounts at the grocery store, we use them when we show a drivers license to order a drink at the bar, and we use them when we show our passport as we enter a foreign country. The use of credentials to demonstrate capability, membership, status, and minimum legal requirements is something that we do on a regular basis as we go about our lives.

A variety of identity and authentication solutions exist today to perform things like single-sign on and limited attribute verification, but they are not widely deployed enough to be ubiquitous on the Web. As a result, these problems exist in the world today because it’s difficult to provide a flexible, digitally verifiable credential:

  • In 2014, 12.7 million U.S. consumers experienced identity fraud losses of over $16B dollars.
  • Over the last 5 years, more than $100B in identity-related fraud losses have been detected in the United States alone. That number is in the several hundreds of billions of dollars worldwide.
  • The cost to law enforcement ranges from $15,000 to $25,000 to investigate each identity theft case; many of them are not investigated. Victims spend, on average, 600 hours trying to clear damaged credit or even criminal records caused by the thief.
  • In 2010, 7 million people self-reported illegal use of prescription drugs in the previous month in the US. These drugs are often acquired through the use of faked credentials. The healthcare costs alone of nonmedical use of prescription opioids – the most commonly misused class of prescription drugs – are estimated to total $72.5 billion annually.
  • Educational and professional service testing fraud has led to multiple hundred million dollar losses when test takers are not who they say they are and the testing agencies are held accountable as a result.
  • Forty thousand legitimate Ph.D.s are awarded annually in the U.S. — while 50,000 spurious Ph.D.s are purchased; that is, more than 50% of new PhDs degrees are fake and more than 500,000 working Americans have a fraudulent degree. More than 25% of job applicants inflate their educational achievements on their resumes.

So, the simple question has been raised in the W3C community: Is it time to do something about Credentials and if so, can W3C add value to the standardization process? Or is this already a solved problem?

Myriad Credentials

There are many different types of credentials in the world and many industry verticals that use credentials in a variety of different ways.

There are many categories of credentials that have been identified as important to society, here are a sample of them:

Education
Academic credentials and co-curricular activities are recognized and exchanged among learners, institutions, employers, or consumers.
Workplace
A worker’s certified skill or license is a condition for employment, professional development, and promotability.
Civil Society
Access to social benefits and contracts may be based on verifiable conditions such as marital status.
Healthcare
Ensuring that medical professionals are properly licensed to write prescriptions for controlled substances or provide certain services to patients.
Finance
Regulations require the proper identification of parties in high value transactions. The legal right to purchase a product depends on the verifiable age or location of the buyer.

The use of credentials is a big part of how our society operates. In order to standardize their usage, it’s important that a generalized mechanism is used to express all the data associated with the types of credentials above. To put it another way, the solution shouldn’t be specific to each category above because there are too many different types of credentials for a single group to standardize. Rather, the solution should be a generalized mechanism that enables verifiable claims to be made about an entity where the contents of the credential can be specified by a specific industry or market vertical (such as university entrance testing, or pharmaceutical distribution, or wealth management).

HTML, CSS, XML, and JSON-LD, are examples of formats that have been used by many different market verticals to encode data. WebRTC, Geolocation, Drag and Drop, and Web Audio are examples of new ways of encoding and exchanging data over the Web that have found use in a variety of industries. Each of these technologies were standardized at W3C.

The purpose of this post is to help build a shared understanding of the use cases for credentials and, in doing so, help accelerate work at W3C. What follows is a list of concerns and hesitations that have been raised over the past several months. It is helpful to discuss these concerns as part of a larger conversation around use cases and technical merits related to the work.

Hesitation #1: The End of Anonymity on the Web

The spectrum of identity needs across diverse use cases suggests there will be different kinds of credentials to match strong privacy use cases and strong identity use cases.

One of the hesitations expressed by privacy proponents is that if we make it easy to identify people using credentials, that we are going to lose anonymity on the Web. The Web started as a largely anonymous medium of communication. In the early days you could jump from site to site without having to identify yourself or expose any personally identifying information. Things have changed for the worse since then with the advent of IP tracking, evercookies, device fingerprinting, browser fingerprinting, email addresses as identifiers, analytics packages, and ad-driven business models. One could argue that anonymity on the Web was lost long ago.

Whether or not you believe that anonymity on the Web is a real thing today, there is a strong argument to not make things worse. Where strong privacy is required, bearer credentials can be used. Where strong identity assurances are required, we can use tightly-bound credentials.

A tightly-bound credential contains a set of claims that are associated with an identifier, effectively stating things like “John Doe is over the age of 21 — signed by some mutually trusted organization or person”. The “John Doe” part of the credential is the problem, because if you provide that credential to multiple websites, you can be tracked across those websites because they know who you are. A tightly-bound credential, however, can contain a link to retrieve a bearer credential. A bearer credential is a short lived, untrackable (by itself) credential that effectively states things like “The holder of this credential is over the age of 21 — signed by some mutually trusted organization or person”.

Bearer credentials do have downsides. Sophisticated attackers can intercept them and replay them across multiple sites. For this reason, bearer credentials have a very short lived lifetime and may not be accepted by credential consumer sites that require a stronger type of authentication such as a tightly-bound credential. That said, there are many websites where using bearer credentials to verify things like age or postal code should be acceptable.

Do bearer credentials ensure anonymity on the Web? No. The only thing you need to do to defeat them is to ask the entity with the bearer credential what their email address is and you have a universally trackable identifier for them. What bearer credentials do, however, is to help not make the tracking problem worse.

Hesitation #2: Credentials as a Gateway Drug

If an easy mechanism exists to ask for personally invasive credentials, it does not necessarily follow that every website will ask for those credentials or that people will willingly hand them over.

Another concern that is often raised is that if there is a good way to strongly identify people via credentials, and the mechanism is easy to use, more websites will require credentials in order to use their services. This is certainly a concern and predicting what will happen here is more difficult particularly because there are many market forces at work.

Websites have varying degrees of utility to people. Depending on each site’s utility, people are willing to give up more or less of their personal information to access the site. A website that is effectively a collection of cat pictures will probably not convince many to give up their email address in exchange for more cat pictures. To provide contrast to the previous example, a personal banking website will most likely be able to convince you to provide far more personally identifiable information. This dynamic will most likely not change as far as it’s clear what information is being transmitted to each site via a credential.

Ultimately, this choice is up to the person sitting behind the browser and the choice must be presented in such a way as to ensure informed consent before the credential is transmitted.

Hesitation #3: We’ve Tried This Before

While it may sound like this has been tried before, the capabilities required to meet the identified goals are more advanced than what the state of the art today supports.

The third major hesitation for not starting the Credentials work as an official work item at W3C is a misconception that many of the identified goals and capabilities are the same as previous attempts at a solution. SAML, InfoCard, Shibboleth, OAuth, OpenID Connect, WebID+TLS, Mozilla Persona; none have solved the credentialing problem stated at the beginning of this blog post in a significant way.

A detailed analysis of each of these initiatives has been performed in a separate blog post titled Credentials: A Retrospective of Mild Successes and Dramatic Failures. Here’s a summary of the state of the art ranked against desired capabilities:

Capability
SAML 2.0
CardSpace
Shibboleth
OAuth 2.0
OpenID Connect
WebID+TLS
Mozilla Persona
Extensible Data Model - - - -
Choice of Syntax
Decentralized Vocabularies - - -
Web-based PKI - - - -
Choice of Storage
App Integration - - -
Privacy-Enhanced Sharing -
Credential Portability - -
Credential Revocation - - - - -

The primary finding of the analysis above is simple: there still is no widely deployed and adopted way of exchanging credentials on the Web today, but we do have quite a bit of insight into why the prior attempts at solving the general identity/credentialing problem have failed.

Hesitation #4: There Is Nothing to Do

While the problem may seem trivial on the surface, to solve it correctly requires carefully understanding the current gaps in the Open Web Platform.

Another assertion that has been made before is that all of the technology necessary to create a robust open credentialing ecosystem on the Web already exists and it is just a simple matter of stringing HTTP, JSON, Javascript Object Signing and Encryption (JOSE), OAuth, OpenID Connect, and a few other technologies together to create the solution. Thus, there is nothing for W3C to do as the problem is more or less solved, and developers only need to be educated about the proper solution.

Clearly, we should reuse existing technologies wherever possible to build a single coherent, stable solution. We do not want to reinvent the wheel.

If it is true that all the technologies already exist, we could quickly solve the problem and move on to other pressing problems on the Web. Unfortunately, this view is not held by the majority of the community that has had contact with the credentialing problem. Participants in the community have tried and failed to implement credentialing solutions using all of the technologies listed at the beginning of this section. It is true that pieces of the solution exist across multiple standardization organizations, but a set of standards for a vibrant credentialing ecosystem do not exist yet as detailed in this blog post: Credentials: A Retrospective of Mild Successes and Dramatic Failures.

We use credentials in our daily lives. We often receive them from one party and then share them with another. If this is a solved problem on the Web, then why is there no similarly vibrant ecosystem of disparate but interoperable Web-based credentialing systems? Where is the specification that outlines how to express a digitally signed credential? Or the protocol for issuing a credential to a storage location? Or the protocol for requesting a credential?

Even if all of the core technologies exist, they have yet to be put together into a coherent, secure, easy to integrate solution for the Web and that sounds like something where the W3C could add value.

Conclusion

This work is worth doing at the W3C because the Open Web Platform doesn’t have a functionality that society depends on to run its education, healthcare, finance, and government sectors. It’s worth doing because fraud is a big problem on the Web for high-stakes exchanges, and the problem is only getting worse. It’s worth doing because the W3C has a platform that 3 billion people around the world use and we could solve this problem at an international scale if successful. It’s worth doing because we plan to add another 3 billion people to the Web in the next 5 years, many of them lacking the basic credentials they need to participate in society, and we can improve upon that condition. It’s worth doing because the W3C membership has solved problems like this before, and has changed the world for the better in doing so.