You might have heard about JWT's, but the JWT specification is just about claims as a payload inside of a JWS, which is apart of the JOSE specification.
In a small series of RFC's, 7515 to 7519, JOSE (JSON Object Signing and Encryption) is defined as a standard that uses cryptographic functions for communication across applications using JSON. JOSE is an effort to modernize a hodgepodge of standards and provides a basic framework for future cryptographic applications all while using the popular and familiar JSON standard. JOSE isn't alway concrete with its recommendations and instead sometimes prefers basic guidance for applications seeking a starting point. JOSE is a needed and welcomed addition to a long history of web standards published using the Internet Engineering Task Force RFC process.
In a small series of RFC's, 7515 to 7519, JOSE (JSON Object Signing and Encryption) is defined as a standard that uses cryptographic functions for communication across applications using JSON. JOSE is an effort to modernize a hodgepodge of standards and provides a basic framework for future cryptographic applications all while using the popular and familiar JSON standard. JOSE isn't alway concrete with its recommendations and instead sometimes prefers basic guidance for applications seeking a starting point. JOSE is a needed and welcomed addition to a long history of web standards published using the Internet Engineering Task Force RFC process.
JOSE is broken into two specifications. JWS (JSON Web Signature) is for signing and integrity protection. JWE (JSON Web Encryption) is for encryption. For some undivined reason JOSE's introduction resulted in much of the web referring to the whole standard as "JWT" (JSON Web Token), a small section of the larger standard. Perhaps it's because of the novel way JOSE was popularized on the web with cookies. JWT claims used in cookies can free servers from remembering session information by trusting the cryptographic signature, originally signed by the server, provided by the client. This novel usage is a small part of a much larger standard, and even this usage highlights the power of JWS. There's nothing special about JWT in a generalized case, as it is simply just a payload.
Perhaps the name "JWT" is popular because of the way JOSE introduced itself in its RFC's. The first RFC in the series concerns JWS and doesn't really explain what JOSE is. Instead the reader is told a JWS header is called a "JOSE header" and that everything else, its payload and signature, is called a "JWS payload" and a "JWS signature" as one would expect. Why would only the header be named "JOSE"? The reader using these clues is initially left to infer JWS is a subset of JOSE. In later RFC's JOSE clearly becomes the given name for the standard as a whole. For example RFC 7520 is titled "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)". This is also made evident in drafts which include JOSE in the name as it is the name of the IETF working group. This information is lost to readers new with the final publishing.
Now back to JWT, a JWS or JWE encapsulates JWT. The JWT specification notes that JWT's are just claims in a JWS.
JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure
JWS is the real star of the show for most web applications, and all these pieces fit together under JOSE.
No comments:
Post a Comment