JWM: a new standard for secure messaging
Messaging technologies have exploded in popularity in recent years. The broad usage of messaging as a framework, especially in distributed systems, requires a dedicated and standardized approach to security. One possible solution to the problem of standards-based secure messaging is to build on top of a family of pre-existing security technologies known as JOSE. JSON Web Message (JWM) is a draft standard aiming to extend the JOSE family to provide the basis for secure messaging systems.
The rise of messaging technologies
Messaging-based systems are not new, however there has been a distinct rise in their popularity over the past few years with the advent of technologies such as messaging apps and remote procedure call protocols like JSON-RPC. One of the distinct benefits of this approach to designing applications is that messages are a flexible and technology-neutral way for many different kinds of devices to interface. Moreover, messages can be adapted to fit a variety of different use cases as they are fairly un-opinionated about the kind of data that is being communicated back and forth. Messaging systems are designed to be asynchronous, which creates a reliable and consistent method for communication in situations where the parties involved aren’t guaranteed to be online at the same time.
The security problem
If we look at the evolution of technology, it is often the case that we build new technologies and then figure out how to make them secure later. The early days of the internet are littered with great examples. For instance, the web started off as just HTTP. This allowed for an enormous number of online interactions, but online shopping wasn’t one of them. The problem was, sending credit card numbers over HTTP made them vulnerable to theft: anyone between you and the server could keep a copy of your card information. HTTPS protocol was introduced around 1994 as an extension of HTTP. That “S” in the abbreviation comes from the word “Secure”, powered by Transport Layer Security (TLS), the standard security technology that establishes an encrypted connection between a web server and a browser. Nowadays, users of the internet are used to seeing HTTPS on nearly every website they visit, and most HTTP-only sites are considered insecure by today’s web browsers.
Messaging technology has evolved in much the same way; email is perhaps our greatest example of secure messaging, however we’ve never quite managed to achieve end-to-end encryption despite the valiant efforts with things like PGP. Because messages are self-encapsulated and are able to transfer multiple hops or be held on servers on behalf of an offline party for later retrieval, solutions like those that rely on TLS such as HTTPS are not always adequate. For example, TLS provides a way to secure content between a server and a mobile device, but it does not offer reliable and uninterrupted ‘content-layer’ security (often referred to as end-to-end encryption). In cases where a message is being sent between two mobile devices via a server and the parties (both the sender and recipients) to the message don’t want the intermediary server to be able to inspect the message, a more robust message-layer solution is needed. Efforts like Signal’s encrypted messaging specification, and more recently Messaging Layer Security (or MLS), among others have emerged to fill the gap. This technology underpins the architecture of popular messaging platforms such as Whatsapp, Signal, and many others.
These protocols go a long way in helping to secure messages online, however with so many different messaging systems on the web, there is a lack of standardization found in the messages being sent back and forth. Most of today’s secure messaging systems cannot communicate with one another, meaning I cannot send a message from my Signal app that can be opened by a user on Whatsapp or Facebook Messenger. These encrypted messaging systems have evolved as complex silos, with no clear path towards interoperability.
With the increasing popularity of messaging systems, there is a need to create a common secure standard in places where multiple vendors want to interoperate, such as in the decentralized identity space. The purpose of a standard, when applied in the right ecosystem, is not only to make it easier for developers to adopt and understand this tech, but to give users the freedom to choose the applications that suit them best.
What is JOSE?
When you are aiming to create a successful standard, ease of implementation is a key factor. To that end, it is useful, when possible, to work within existing frameworks that developers are familiar with. JOSE, which stands for Javascript Object Signing and Encryption, is one such family of specifications. JOSE standards are widely used by application developers who want to implement signing and encryption into their applications and platforms. These standards help make systems more secure in addition to creating a simple and reliable way for developers to access these security features. While JOSE specifications have primarily been implemented to address identity and access management on the web, in theory it is possible to leverage these standards for a broader set of use cases and contexts where security is a desirable property. Messaging is an obvious candidate for this work, and JOSE has already proven incredibly successful with a ton of existing infrastructure out in the wild that we can benefit from. As such, JWM, or JSON Web Message aims to extend the JOSE family to provide the basis for secure messaging systems.
JWS, or JSON Web Signature, defines a standard method for applying a digital signature to a payload. The purpose of this signature is to demonstrate origin authenticity and/or content integrity protection, verifying that the JSON payload hasn’t been tampered with. The resulting signature can be expressed in multiple formats, including one that makes it suitable for embedding in a URL or HTTP header.
JWE, or JSON Web Encryption, enables applications to achieve confidentiality (among other properties) by defining a method for encrypting a payload. This standard allows for content to be encrypted* for a particular audience*. Again, much like JWS it can be expressed in multiple formats, including one that makes the resulting cipher suitable for embedding in a URL or HTTP header.
Although JWS and JWE were defined as standalone specifications, the most immediate application of these came from another standard that was developed at the same time called JSON Web Token, or JWT. JWT is a secure format enabling an issuer of a token to express claims about a subject to an audience. This token can feature multiple different security properties; it can combine with JWS to become a digitally signed token and/or it can combine with JWE to become an encrypted token. In other words, JWT utilizes the JWS and JWE standards for the specific purpose of creating secure tokens, which have many applications in identity systems specifically around authentication and authorization.
The relationship between JWS, JWE, and JWT
Motivation for JWM
JWTs are a simple but powerful construct for creating secure tokens, however they are not suited for all applications where digital signing and/or encryption are desired. In the case of messaging, we want to leverage the benefits provided by the standardization protected formats such as JWS and JWE, but for something other than creating secure tokens. This has prompted the design of the draft standard known as JWM. JSON Web Message follows the example of JWT in terms of structure and relationship to JWS and JWE, but makes several important design decisions which differ from JWT in order to better realize secure messaging protocols.
A bit about JWMs
JWM aims to create an approachable basis for standardized secure messaging leveraging popular web technologies. Essentially, a JWM is a way for a sender to create a message for one or more recipients with some common properties used in messaging protocols. A JWM, like a JWT, can be protected/secured in one of two ways; it can combine with JWS to become a digitally signed message, and/or it can combine with JWE to become an encrypted message.
The relationship between JWS, JWE, JWT, and JWM
Apart from the difference in intent of a JWM to a JWT, another key distinction is that JWMs allow the ability for multiple signatures and multi-party encryption. Because JWTs were designed to be as concise as possible, they must be expressed in a compact format suitable for embedding in a URL or HTTP header. This constraint limits JWT to only a single signature, or a single recipient in the case of encryption.
Another key part of the JWM specification is the definition of message attributes which are bits of information conveyed by a message. In addition to this concept, the specification also loosely defines what are regarded as core attributes, or attributes that we expect many consumers and producers of JWMs to commonly use. For example, if we think about email or Postal Mail (both common kinds of messages we encounter) we often want to know who the message is from, who the message is for, how to reply to the message, who to direct a reply to, when the message was sent, and how the message is related to other messages (if it is a part of an ongoing message chain such as an email thread). JWM defines these attributes, and a few others, in an extensible manner, enabling producers and consumers of messages to remain interoperable while leaving room for future enhancement.
JWM aims to create an approachable basis for standardized secure messaging leveraging popular web technologies.
JWMs, due to the flexibility provided by JWS and JWE standards, do not require usage of specific cryptographic primitives and hence can leverage the broad spectrum of work that exists in today’s messaging systems, as well as ones that may be needed in the future. This includes the aforementioned cryptographic protocols of MLS and Signal, which, when combined with JWM, allow developers to achieve highly secure and standardized message-based architectures.
There are likely several use cases for JWMs, however there are some immediate applications surrounding decentralized identity. Members of the W3C Community Credentials Group, Hyperledger Aries Working Groups, and Decentralized Identity Foundation (DIF) are hard at work implementing technologies around Decentralized Identifiers (DIDs), a standard in active development at the W3C aiming to realize a layer of Decentralized Public Key Infrastructure (DPKI) to exchange verifiable credentials and other verifiable data on the internet. To achieve a truly decentralized and open internet where user privacy and freedom of choice is of the utmost importance, a common approach has been to use message-based architectures such as JWM which unify various kinds of distributed applications.
Summing things up
JWM is a simple, standard, but flexible way to send secure messages over the web. By using the existing popular and extensible formats defined by JWS and JWE, we can achieve strong re-use of existing capabilities available today throughout open-source communities while opening the door to an exciting new group of use-cases.
We invite both developers of JOSE-related libraries and those interested in standards-based secure messaging to get involved with the ongoing work on JWMs. There are a number of ways to contribute to this work, such as offering feedback to the spec in the form of issues and comments, writing implementations against the spec, and adding support for JWMs to existing JOSE libraries.
To find out more please visit the JWM Draft Spec, check out our Github repo, or reach out to the MATTR team at info@mattr.global. We are looking forward to exploring the possibilities that this new draft specification introduces for developers across the web.