Secure Webhook Token (SWT)
draft-knauer-secure-webhook-token-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Stephan Knauer | ||
| Last updated | 2026-05-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-knauer-secure-webhook-token-02
Network Working Group S. Knauer
Internet-Draft 14 May 2026
Intended status: Standards Track
Expires: 15 November 2026
Secure Webhook Token (SWT)
draft-knauer-secure-webhook-token-02
Abstract
The Secure Webhook Token (SWT) is a specialized JSON Web Token (JWT)
format designed for securely authorizing and verifying webhook
requests. It defines a set of claims to ensure that the token is
explicitly tied to webhook events and that its integrity can be
reliably validated by the recipient. A key feature of SWT is the
introduction of a unique claim, webhook, which encapsulates webhook-
specific information, such as the event type.
By providing a structured and secure approach to webhook
authentication, SWT aims to be a lightweight and flexible solution
while maintaining compatibility with typical JWT structures. It is
designed with the best practices in mind and may serve as a
foundation for future standardization efforts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Knauer Expires 15 November 2026 [Page 1]
Internet-Draft SWT May 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Secure Webhook Token (SWT) Overview . . . . . . . . . . . . . 3
3. Transport Requirements . . . . . . . . . . . . . . . . . . . 3
4. Token Size Limitation . . . . . . . . . . . . . . . . . . . . 3
5. JWT Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. Example Header Structure . . . . . . . . . . . . . . 4
5.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2.1. Example Payload Structure . . . . . . . . . . . . . . 5
6. Request Body Integrity . . . . . . . . . . . . . . . . . . . 6
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Server-side Processing . . . . . . . . . . . . . . . . . 7
6.3.1. Recommendations . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Interoperability Considerations . . . . . . . . . . . . . . . 9
9. Signing and Encryption Recommendations . . . . . . . . . . . 9
9.1. Encrypted JWT Support (JWE) . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10.1. Media Type Registration . . . . . . . . . . . . . . . . 10
10.2. JSON Web Token Claims Registration . . . . . . . . . . . 10
10.3. JWT webhook claim . . . . . . . . . . . . . . . . . . . 11
10.3.1. Examples of JWT webhook claim . . . . . . . . . . . 11
11. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1.1. Example 1: Empty body (notification only) . . . . . 12
11.1.2. Example 2: Non-empty body with hash . . . . . . . . 13
12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Knauer Expires 15 November 2026 [Page 2]
Internet-Draft SWT May 2026
1. Introduction
The increasing use of webhooks requires a secure, standardized
approach to authorizing webhook requests and verifying the sender's
authenticity. The SWT specifies a JWT-based [RFC7519] structure,
which includes unique claims tailored for webhook events. This
specification mandates that all tokens must be transmitted using HTTP
POST requests (see Section 9.3.3 of [RFC9110]), with the token in the
Authorization header and event data in the request body, ensuring
secure transmission and optimal compatibility with typical HTTP
implementations.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
The interpretation should only be applied when the terms appear in
all capital letters.
2. Secure Webhook Token (SWT) Overview
This specification defines required claims within the JWT [RFC7519]
payload and prescribes the transport protocol as HTTP POST. The
token is transmitted in the Authorization header while the webhook
event data is sent in the request body. These constraints ensure
interoperability across diverse systems and provide a consistent
approach to webhook authorization.
3. Transport Requirements
SWTs MUST be transmitted using HTTP POST requests only.
The token MUST be included in the Authorization header using the
Bearer scheme, while the webhook event data MUST be sent in the
request body.
4. Token Size Limitation
*Recommended Maximum Token Size*: While there is no strict maximum
size for an SWT, the token SHOULD be kept concise, containing only
essential claims to support efficient processing and minimize
resource usage. The primary use case for SWTs is to securely
authorize and trigger events rather than transmit extensive data.
Knauer Expires 15 November 2026 [Page 3]
Internet-Draft SWT May 2026
*Header Size Considerations*: Since the token is transmitted in the
Authorization header, implementers should be aware of HTTP header
size limits imposed by web servers and proxies. Most web servers
have a default maximum HTTP header size of 8KB, though this can often
be configured. To ensure broad compatibility, the JWT token itself
SHOULD remain reasonably small (typically under 4KB).
5. JWT Structure
An SWT comprises the following:
5.1. Header
* *alg*: Specifies the signing algorithm [RFC7518], typically
"HS256" (HMAC SHA-256).
* *typ*: Specifies the token type, which MUST be "SWT". This
distinguishes Secure Webhook Tokens from generic JWTs and enables
recipients to recognize and process them according to this
specification.
5.1.1. Example Header Structure
{
"alg": "HS256",
"typ": "SWT"
}
5.2. Payload
The payload contains the following required claims, carefully chosen
to meet security and identification needs:
* *webhook*: Custom claim specific to this specification.
- *event*: Describes the webhook event type (e.g.,
"payment.received"). Values should be concise to meet the size
limitations.
- *hash* (OPTIONAL): The cryptographic hash of the request body
(see Request Body Integrity (#request-body-integrity)). This
field MUST be present when the request body is non-empty and
MUST be omitted when the request body is empty.
- *retry_count* (OPTIONAL): A non-negative integer indicating the
delivery attempt number (0 = initial attempt, 1+ = retry). See
JWT webhook claim (#webhook-claim-specification) for detailed
specification.
Knauer Expires 15 November 2026 [Page 4]
Internet-Draft SWT May 2026
* *iss* (Issuer): Identifies the token issuer (e.g., a unique name
or domain representing the entity). Short, meaningful identifiers
are RECOMMENDED.
* *sub* (Subject) (OPTIONAL): While traditionally used to identify
the principal subject of a JWT, the sub claim is not required in
SWT. The purpose and intent of the token are unambiguously
defined by the webhook claim. However, implementers may include
sub to identify the system, service, or entity responsible for
issuing the token, if such context is useful.
* *exp* (Expiration): Specifies the token's expiration time as a
Unix timestamp. This prevents tokens from being valid
indefinitely.
* *nbf* (Not Before): Specifies the earliest time the token is
considered valid, using a Unix timestamp.
* *iat* (Issued At): The timestamp when the token was issued, aiding
in token age validation.
* *jti* (JWT ID): A unique identifier for each token to prevent
replay attacks. A UUID [RFC9562] or similarly unique identifier
is RECOMMENDED.
5.2.1. Example Payload Structure
5.2.1.1. SWT payload with empty body (notification only):
{
"webhook": {
"event": "ping"
},
"exp": 1733987961,
"nbf": 1733987661,
"iat": 1733987661,
"iss": "swt.example.com",
"jti": "2020B14D-C365-4BCF-84CD-5D423E0C6687"
}
5.2.1.2. SWT payload with body content:
Knauer Expires 15 November 2026 [Page 5]
Internet-Draft SWT May 2026
{
"webhook": {
"event": "delivery.scheduled",
"hash": "sha-256:22b793b7c031e6a3...05ba920b",
"retry_count": 0
},
"exp": 1733987961,
"nbf": 1733987661,
"iat": 1733987661,
"iss": "swt.example.com",
"jti": "2020B14D-C365-4BCF-84CD-5D423E0C6687"
}
5.2.1.3. SWT payload for retry attempt:
{
"webhook": {
"event": "delivery.scheduled",
"hash": "sha-256:22b793b7c031e6a3...05ba920b",
"retry_count": 3
},
"exp": 1733988561,
"nbf": 1733988261,
"iat": 1733988261,
"iss": "swt.example.com",
"jti": "A1C3F89E-2F4D-4A8C-9B2E-7D8F1C3E5A9B"
}
6. Request Body Integrity
6.1. Overview
To ensure payload integrity when sending body content, webhook
requests with non-empty request bodies MUST include a cryptographic
hash of the request body. Instead of using separate fields for
algorithm and value, a self-describing hash field is used:
"webhook": {
"event": "delivery.scheduled",
"hash": "sha-512:f8f24b01df358f10...df03db5cf"
}
This format allows the server to interpret the algorithm dynamically
and accept or reject hashes according to its policies.
Knauer Expires 15 November 2026 [Page 6]
Internet-Draft SWT May 2026
6.2. Format
hash = "<algorithm>:<hash_value>"
* <algorithm>: The cryptographic hash algorithm, using standardized
names such as sha-256, sha-512, sha3-256.
* <hash_value>: The lowercase hexadecimal representation of the hash
of the request body. Hexadecimal encoding is REQUIRED for
interoperability.
6.2.1. Examples
"hash": "sha-256:04ef96c3bc56b3c4...200a5353"
"hash": "sha-512:f8f24b01df358f10...df03db5cf"
6.3. Server-side Processing
1. Parse the hash string to separate algorithm and value.
[algo, value] = hash.split(":")
2. Validate the algorithm against the server’s allowed list.
3. Compute the hash of the received payload using algo.
4. Compare computed hash with value.
* If they match → payload integrity verified.
* If they do not match → reject the webhook request.
6.3.1. Recommendations
* Algorithm Registry: Use standardized algorithm names aligned with
the IANA Named Information Hash Algorithm Registry [RFC6920] to
avoid ambiguities.
* Extensibility: New hash algorithms may be introduced without
changing the JSON schema.
* Security Note: Do not accept weak or deprecated hash algorithms
(e.g., MD5, SHA-1).
7. Security Considerations
1. *Signature Verification*: Receivers MUST verify the JWT signature
before processing any claims. Failure to verify signatures
exposes the system to token forgery attacks. The signature
algorithm specified in the JWT header MUST be validated against
an allowlist of permitted algorithms to prevent algorithm
substitution attacks.
Knauer Expires 15 November 2026 [Page 7]
Internet-Draft SWT May 2026
2. *Algorithm Allowlist*: Implementations MUST maintain an allowlist
of acceptable signing algorithms and MUST reject tokens signed
with algorithms not on this list. The alg header parameter MUST
be checked against this allowlist before signature verification.
Implementations MUST NOT accept the "none" algorithm.
3. *HTTPS Transport*: It is REQUIRED that SWT transmissions occur
over HTTPS to ensure the token's confidentiality and protect
against man-in-the-middle attacks.
4. *Replay Protection*: The jti claim MUST be checked for uniqueness
on the server side to prevent replay attacks. Each jti value
MUST only be accepted once within the token's validity period.
Implementations SHOULD maintain a cache or registry of seen jti
values.
5. *Expiration and Time-based Claims*: Systems MUST validate the
exp, nbf, and iat claims to ensure tokens are used only within
their intended validity period. Implementations SHOULD allow for
a small clock skew tolerance (e.g., 60 seconds) when validating
time-based claims to account for clock differences between
systems. Token lifetime (exp - iat) SHOULD be kept as short as
practical for the use case, typically not exceeding 15 minutes
for most webhook scenarios.
6. *Key Management*: Symmetric keys used for HMAC algorithms MUST be
generated using a cryptographically secure random number
generator and MUST have sufficient entropy (at least 256 bits for
HS256). Keys SHOULD be rotated regularly. For asymmetric
algorithms, private keys MUST be protected with appropriate
access controls and SHOULD be stored in hardware security modules
(HSMs) or key management systems (KMS) when available.
7. *Hash Algorithm Security*: When validating request body hashes,
implementations MUST reject weak or deprecated hash algorithms
(e.g., MD5, SHA-1). Only cryptographically strong hash
algorithms (SHA-256 or stronger) SHOULD be accepted.
8. *Respect Header Limits*: Excessively large JWT tokens SHOULD be
avoided to ensure compatibility with HTTP header size limits
imposed by web servers and proxies.
9. *Retry Count Validation*: When the retry_count field is present,
receivers SHOULD validate that its value is reasonable to prevent
abuse. Implementations MAY enforce maximum retry limits (e.g.,
rejecting requests with retry_count exceeding a configured
threshold) to protect against resource exhaustion attacks. The
retry_count value MUST be a non-negative integer. Receivers
Knauer Expires 15 November 2026 [Page 8]
Internet-Draft SWT May 2026
SHOULD consider implementing exponential backoff expectations and
MAY reject retry attempts that arrive too quickly relative to the
retry_count value. Additionally, the combination of jti and
retry_count should be considered together: each retry attempt
MUST use a unique jti value, as retries represent distinct
delivery attempts even when delivering the same event.
8. Interoperability Considerations
SWT's use of standard HTTP POST requests with JWT-based authorization
ensures broad compatibility with existing web infrastructure. The
structure is simple to parse and easy to integrate with existing JWT
validation libraries. The separation of token metadata and event
data provides flexibility for various payload sizes and content
types.
9. Signing and Encryption Recommendations
To maintain a balance between security and usability, SWTs are
RECOMMENDED to be used as JSON Web Signatures (JWS) [RFC7515],
specifically signed JWTs. This provides data integrity and allows
the recipient to verify the token's authenticity. The following
signing algorithms are suggested for SWTs, as they offer a secure yet
practical approach:
* HS256, HS384, and HS512: Symmetric algorithms using HMAC with SHA-
256, SHA-384, and SHA-512, respectively. These algorithms are
considered secure and performant for most applications, especially
when using shared symmetric keys between the issuer and the
receiver.
While these symmetric algorithms are RECOMMENDED for ease of use and
efficiency, other supported algorithms, including asymmetric methods
such as RS256 (RSA with SHA-256) or ES256 (ECDSA with SHA-256), MAY
also be used if needed based on security requirements or system
constraints.
9.1. Encrypted JWT Support (JWE)
In addition to JWS, SWT allows the use of the JSON Web Encryption
(JWE) [RFC7516] standard if encrypted JWTs are required to protect
sensitive data within the token. JWE adds encryption layers to JWTs,
providing confidentiality as well as integrity protection, which may
be appropriate in contexts where tokens contain sensitive
information.
10. IANA Considerations
Knauer Expires 15 November 2026 [Page 9]
Internet-Draft SWT May 2026
10.1. Media Type Registration
This specification registers the application/swt+jwt media type in
the IANA "Media Types" registry in the manner described in [RFC6838].
The following entries should be registered:
* Type name: application
* Subtype name: swt+jwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: 8-bit; application/swt+jwt values are
encoded as a series of base64url-encoded values (some of which may
be the empty string) separated by period ('.') characters
* Security considerations: See Security Considerations section of
this document
* Interoperability considerations: n/a
* Published specification: This document
* Applications that use this media type: Webhook delivery systems,
event notification platforms, and applications requiring secure
webhook authentication
* Fragment identifier considerations: n/a
* Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information: Stephan
Knauer, mail@knauer.consulting
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Stephan Knauer, mail@knauer.consulting
* Change controller: IESG
* Provisional registration? No
10.2. JSON Web Token Claims Registration
This document updates the IANA "JSON Web Token Claims" registry for
JWT Claim Names. Following the format in Section 10.1.1 of
[RFC7519], the following should be registered.
* Claim Name: "webhook"
* Claim Description: Webhook
* Change Controller: IESG
* Specification Document(s): Section 10.3 of this document
Knauer Expires 15 November 2026 [Page 10]
Internet-Draft SWT May 2026
10.3. JWT webhook claim
The webhook claim is a JSON object that describes the event to be
triggered and optionally includes metadata about the event data sent
in the request body.
It consists of the following fields:
* event: A case-sensitive string describing the name of the webhook
event. It should be concise and specific (e.g., "order.created").
* hash (OPTIONAL): The hash algorithm and the hash digest of the
request body payload (hex-encoded) (see Section 6).
- This field MUST be present when the request body is non-empty
(Content-Length > 0).
- This field SHOULD be omitted when the request body is empty
(Content-Length = 0).
* retry_count (OPTIONAL): A non-negative integer indicating the
delivery attempt number for this webhook event.
- A value of 0 indicates the initial delivery attempt (no retry).
- A value of 1 or greater indicates a retry attempt (e.g., 1 =
first retry, 2 = second retry).
- This field SHOULD be included when the webhook system
implements retry logic for failed deliveries.
- Receivers MAY use this value to implement progressive backoff
strategies, rate limiting, or to decide whether to accept
further retries.
Implementers MAY restrict the set of supported algorithms based on
their security posture.
| Senders and receivers SHOULD agree on supported algorithms in
| advance.
|
| Although NOT RECOMMENDED, it may be necessary to send non-JSON
| event data via SWT. The HTTP _Content-Type_ header SHOULD be set
| accordingly.
10.3.1. Examples of JWT webhook claim
Initial delivery attempt:
"webhook": {
"event": "issue.opened",
"hash": "sha-256:04ef96c3bc56b3c4...200a5353",
"retry_count": 0
}
Retry attempt:
Knauer Expires 15 November 2026 [Page 11]
Internet-Draft SWT May 2026
"webhook": {
"event": "issue.opened",
"hash": "sha-256:04ef96c3bc56b3c4...200a5353",
"retry_count": 2
}
11. Validation
To validate an SWT, the receiving system MUST perform the following
checks:
1. *JWT Validation*: The token in the Authorization header MUST be a
valid JWT with all required claims.
2. *Webhook Claim Validation*: The JWT MUST contain a webhook claim
with an event field.
3. *Body and Hash Validation*:
* *If the request body is non-empty* (Content-Length > 0):
- The webhook claim MUST contain a hash field.
- The computed hash of the request body MUST match the hash
value specified in the webhook claim using the specified
algorithm.
* *If the request body is empty* (Content-Length = 0):
- The webhook claim MUST NOT contain a hash field.
If any validation check fails, the server SHOULD respond with an
appropriate HTTP error code:
* *401 Unauthorized*: If JWT signature verification fails, the token
is expired, or authentication credentials are invalid.
* *403 Forbidden*: If the token is valid but the issuer lacks
permission to trigger the webhook or access the resource.
* *400 Bad Request*: If the request is malformed (e.g., missing
required claims, invalid hash format, or hash mismatch).
11.1. Examples
11.1.1. Example 1: Empty body (notification only)
*Webhook claim:*
Knauer Expires 15 November 2026 [Page 12]
Internet-Draft SWT May 2026
{
"webhook": {
"event": "ping"
},
"exp": 1733987961,
"nbf": 1733987661,
"iat": 1733987661,
"iss": "swt.example.com",
"jti": "2020B14D-C365-4BCF-84CD-5D423E0C6687"
}
*POST request:*
POST /webhook HTTP/1.1
Content-Length: 0
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...
Host: example.com
11.1.2. Example 2: Non-empty body with hash
*Webhook claim:*
{
"webhook": {
"event": "issue.opened",
"hash": "sha-256:04ef96c3bc56b3c4...200a5353",
"retry_count": 0
},
"exp": 1733987961,
"nbf": 1733987661,
"iat": 1733987661,
"iss": "swt.example.com",
"jti": "2020B14D-C365-4BCF-84CD-5D423E0C6687"
}
*POST request:*
Knauer Expires 15 November 2026 [Page 13]
Internet-Draft SWT May 2026
POST /webhook HTTP/1.1
Content-Length: 6123
Content-Type: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...
Host: example.com
{
"action": "opened",
"issue": {
"url": "https://api.github.com/repos/octocat/...",
"number": 1347,
...
},
"repository" : {
"id": 1296269,
"full_name": "octocat/Hello-World",
"owner": {
"login": "octocat",
"id": 1,
...
},
...
},
"sender": {
"login": "octocat",
"id": 1,
...
}
}
12. Conclusion
The Secure Webhook Token (SWT) format provides a secure,
interoperable, and efficient solution for webhook authentication.
Its focus on signed payloads, minimal overhead, and clear transport
guidance makes it suitable for modern web service ecosystems.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Knauer Expires 15 November 2026 [Page 14]
Internet-Draft SWT May 2026
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
13.2. Informative References
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
Author's Address
Stephan Knauer
Leipzig, SN
Germany
Email: mail@knauer.consulting
Knauer Expires 15 November 2026 [Page 15]