Skip to main content

Appendix F. Detached Content

Appendix F. Detached Content​

This appendix demonstrates how to represent JWSs with detached content -- where the payload is not embedded in the JWS itself but is transmitted or stored separately.

Use Case​

Detached content is useful when:

  • The payload is large and transmitting it multiple times is inefficient
  • The payload is already available to the recipient through other means
  • The signature needs to be stored or transmitted separately from the payload

JWS Compact Serialization with Detached Content​

In the JWS Compact Serialization, detached content is represented by omitting the payload portion while retaining the period separators:

BASE64URL(UTF8(JWS Protected Header)) || '.' || '' || '.' || BASE64URL(JWS Signature)

This results in two consecutive period characters where the payload would normally be.

Example​

A JWS with detached content might look like:

eyJhbGciOiJIUzI1NiJ9..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Note the double period ('..') indicating the absent payload.

Validation​

When validating a JWS with detached content:

  1. Obtain the payload through an application-specific mechanism
  2. Compute BASE64URL(JWS Payload)
  3. Reconstruct the complete JWS Signing Input: BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)
  4. Validate the signature using the reconstructed Signing Input

JWS JSON Serialization with Detached Content​

In the JWS JSON Serialization, the "payload" member is simply omitted from the JSON object. The recipient must obtain the payload value through other means and use it during signature validation.

Security Considerations​

Applications using detached content must ensure that:

  • The correct payload is associated with the signature
  • The payload cannot be substituted by an attacker
  • The mechanism for payload transmission/storage maintains integrity
Last updated on