5. JOSE Header
For a JWT object, the members of the JSON object represented by the JOSE Header describe the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. Depending upon whether the JWT is a JWS or JWE, the corresponding rules for the JOSE Header values apply.
This specification further specifies the use of the following Header Parameters in both the cases where the JWT is a JWS and where it is a JWE.
5.1. "typ" (Type) Header Parameter
The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used by JWT applications to declare the media type [IANA.MediaTypes] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when the kind of object is already known. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL.
5.2. "cty" (Content Type) Header Parameter
The "cty" (content type) Header Parameter defined by [JWS] and [JWE] is used by this specification to convey structural information about the JWT.
In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is NOT RECOMMENDED. In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWT", to indicate that a Nested JWT is carried in this JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. See Appendix A.2 for an example of a Nested JWT.
5.3. Replicating Claims as Header Parameters
In some applications, it is useful to have certain claims be directly visible to software processing the JWT, without having to first decrypt or verify the JWT. This can be accomplished by replicating the claim values as Header Parameter values.
This specification does not require or forbid the replication of claims in Header Parameters. However, applications choosing to do so MUST follow these rules:
-
The claim presence and value semantics MUST be preserved, whether the claim is in the JWT Claims Set or as a Header Parameter.
-
If the same information is present in both locations, their values MUST be identical. Implementations MUST verify this consistency and reject the JWT if they are inconsistent.