Standardization of JSON Web Signature, a method for adding signatures to JSON, has begun in the IETF JOSE Working Group [1].
The initial draft
My name is mentioned here because I brought the ideas being considered in the OpenID Foundation's AB/C Working Group to the IETF[2].
@ritou said, "What is a signed request in the OAuth 2.0 era?" As mentioned in the entry, Facebook signed_request very similar to
The big difference is that signed_request
Signature . Body
whereas in JWS,
Header . Body . Signature
There is a reason for this.
Why "header . body . signature"?
Some may argue that we should just do the same as the global leader, Facebook, but there is a good logical reason why we have adopted this format.
Why are the headers separated?
In the case of signed_request , the signature parameters are included in the body of the message. If you want to encrypt the body of the message, this approach cannot be used because the parameters to decrypt the message would also be encrypted. Therefore, you need to separate these encryption-related parameters into the header section.
JWS tries to have as much in common as possible with JWE, which is why it was necessary to separate the headers.
Why is the signature at the end?
Another big difference in appearance is that in signed_request, the signature is at the beginning, whereas in JWS, it is at the end. In JWS, the signature is placed at the end in order to stream the signature creation. This is because if you try to add the signature at the beginning, all data must be buffered until the signing process is complete, and then sent out as "signature.body" after signing is complete, whereas if you put the signature at the end, data can be sent out one after another, so there is no need to buffer all the data, which is "kinder" to server resources. There is not much difference if only very small pieces of data are signed, as in signed_request, but this consideration has been taken into account since JWS may sign huge amounts of data.
common characteristics
There are some common features between singed_request and JWS. The most typical ones are:
- No data normalization is performed
- Use base64url for serialization
- Use JSON as the data format.
- Any data can be signed
No data normalization is performed
There is a standard called XML Digital Signature. It is very versatile and flexible. However, it has been said that it has low compatibility between different implementations, and it has been disliked by many developers. The biggest reason for this seems to be the canonicalization of XML data. To avoid this problem, neither signed_request nor JWS performs any canonicalization. They use the original data as is.
Use base64url for serialization
I am often asked why I use base64url instead of base64. The answer is that base64url contains characters that are not Web Safe, such as "=". JWS is inserted into HTTP headers and GET and POST parameters. In that case, it is better not to pad with "=" than to escape "=" every time.
Use JSON as the data format
The reason we use JSON instead of XML is that it is more compact, has better processing performance, and most importantly, is more popular with developers.
Any data can be signed
Although this is a method for signing JSON, you can sign any data by simply entering base64url encoded data into one of the JSON parameters.
Who Uses JWS?
I hope you understand why there is such a difference. But you might be thinking, "What's the point if Facebook doesn't use it?" Here's my answer to that question:
First, it's not that Facebook has decided not to use it. They're just happy with the current signed_request and don't see the need to use JWS for that purpose. They may use it for other purposes. Also, if JWS becomes more common in the long run, is it possible that "developer-friendly" Facebook will add support for it?
And even if Facebook doesn't use it, many other players are expected to. Currently, these include Microsoft, Google, Salesforce, AOL, and eBay.
When should I respond?
I think JWS is relatively sophisticated. In fact, Google, eBay, and others have implemented it. So, if you don't mind some changes, I think it's a good idea to start following it now [3]. If you have a signing need, please consider using JWS.
[1] At the same time, a standardization of encryption called JSON Web Encryption has begun.
[2] Because it can be used not only in identity standards such as OpenID Connect but also in general purposes, we decided to standardize it at the IETF. Other specifications brought in in a similar way include JSON Web Token and Simple Web Discovery.
[3] Meanwhile, JWE is about to undergo some surgery. Specifically, we will add an Integrity Check as a MUST when using CBC mode. So, until the next draft,
Is it a bad idea to normalize semi-structured data? I wanted to normalize it to get a hash to quickly compare whether JSON objects match or not, but...