Better explain why not JWS.

Author: MarkLodato

README.md

@@ -27,8 +27,8 @@ Out of scope (for now at least):
 ## Why not...?
 
 *   Why not raw signatures? Too fragile.
-*   Why not [JOSE/JWS/JWT](https://jwt.io)? JSON-specific, too complicated, too
-    easy to mess up.
+*   Why not [JWS](https://tools.ietf.org/html/rfc7515)? Too many insecure
+    implementations and features.
 *   Why not [PASETO](https://paseto.io)? JSON-specific, too opinionated.
 *   Why not the legacy TUF/in-toto signature scheme? JSON-specific, relies on
     canonicalization.

background.md

@@ -20,7 +20,12 @@ There is no other simple, foolproof signature scheme that we are aware of.
     JSON-specific and relies on [canonicalization](motivation.md), which is an
     unnecessarily large attack surface.
 
-*   [JWS] is JSON-specific, complicated, and error-prone.
+*   [JWS], though popular, has a history of
+    [vulnerable implementations](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/)
+    due to the complexity and lack of specificity in the RFC, such as not
+    verifying that `alg` matches the public key type or not verifying the root
+    CA for `x5c`. It also requires a JSON library even if the payload is not
+    JSON, though this is a minor issue.
 
 *   [PASETO] is JSON-specific and too opinionated. For example, it mandates
     ed25519 signatures, which may not be useful in all cases.