776 VIEWS
Pinterest LinkedIn LINE

Standardization of JSON Web Signature, a standard for attaching signatures to JSON, has begun in the IETF JOSE Working Group[1].

The initial draft is:

My name appears in it because we brought work that had been under consideration in the OpenID Foundation’s AB/C Working Group to the IETF[2].

As @ritou noted in the post “What Are Signed Requests in the OAuth 2.0 Era?,” it closely resembles Facebook’s signed_request.

The major difference is that signed_request uses the format:

signature . body

whereas JWS uses:

header . body . signature

There are reasons for this.

Why “header . body . signature”?

Some may argue that we should simply use the same format as Facebook, the ruler of the world. But there are sound logical reasons why this format was chosen.

Why the Header Is Separate

In signed_request, the signature parameters are included in the body. This approach cannot be used when the body is to be encrypted, because even the parameters needed for decryption would be encrypted. These encryption-related parameters therefore need to be separated into a header.

JWS is designed to share as much as possible with JWE. It was therefore necessary to separate the header.

Why the Signature Comes Last

Another major visible difference is that the signature comes first in signed_request but last in JWS. JWS places the signature last to allow signature generation to be streamed. If the signature were placed first, all data would have to be buffered until the signing process finished and then sent as “signature.body.” When the signature comes last, data can be sent continuously, eliminating the need to buffer everything and making the process kinder to server resources. This makes little difference if, like signed_request, only small, fixed-format data is signed. JWS, however, may be used to sign very large data, so this consideration was incorporated.

Common Features

signed_request and JWS also have features in common. Representative examples are:

  • No data canonicalization
  • Use base64url for serialization
  • Use JSON as the data format
  • Ability to sign arbitrary data

No Data Canonicalization

There is a standard called XML Digital Signature. It is highly general and flexible. However, it has long been said to have poor interoperability among different implementations and has been disliked by many developers. The main reason is probably the canonicalization of XML data. To avoid this problem, neither signed_request nor JWS performs any canonicalization. They use the original data exactly as it is.

Use base64url for Serialization

People often ask why base64url is used instead of base64. The answer is that base64 contains characters such as “=” that are not web-safe. JWS may be placed in an HTTP header or in GET or POST parameters. Rather than escaping “=” every time, it is better not to use “=” padding.

Use JSON as the Data Format

JSON is used instead of XML because it is more compact, makes good processing performance easier to achieve, and, above all, is popular with developers.

Ability to Sign Arbitrary Data

Although it is nominally a method for signing JSON, arbitrary data can be signed simply by putting base64url-encoded data into one of the JSON parameters.

Who Will Use JWS?

I think the reasons for these differences should now be clear. But you may wonder, “Isn’t it pointless if Facebook won’t use it?” My answer is as follows.

First, Facebook has not decided not to use it. They are satisfied with their current signed_request and simply do not see a need to use JWS for that purpose. They may use it for other purposes. Also, if JWS becomes common over the long term, perhaps developer-friendly Facebook might add support for it.

Even if Facebook does not use it, many other players are expected to do so. At present, these include Microsoft, Google, Salesforce, AOL, and eBay.

When Should You Support It?

I think JWS is relatively mature. Google, eBay, and others have already implemented it. Therefore, if you can accept that there may be some changes, I think it is reasonable to start following it now[3]. If you have a need for signatures, please consider using JWS.

[1] At the same time, standardization of encryption under the name JSON Web Encryption has also begun.

[2] We decided to standardize it at the IETF because it can be used generally, not only in identity standards such as OpenID Connect. Other specifications brought to the IETF in the same way include JSON Web Token and Simple Web Discovery.

[3] JWE, on the other hand, is about to undergo some minor surgery. Specifically, when CBC mode is used, an Integrity Check will be added as a MUST. Therefore, until the next draft

Related posts