Understand the security limits
04A recognizable marker is a handling aid, not encryption, randomness or a complete security system. Registration status and publication status also describe different things.
Marker detection, suitable entropy and safe handling are separate concerns. The RFC cannot prevent intentional disclosure and specifies no encryption mechanism.
Source for this drawing: RFC 8959 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The grammar permits a one-character token, but that is not recommended practice. Applications should evaluate entropy needs and issue tokens accordingly; this RFC sets no universal minimum length.
- The grammar permits a one-character token, but that is not recommended practice. Applications should evaluate entropy needs and issue tokens accordingly; this RFC sets no universal minimum length.
- The scheme aims to reduce accidental disclosure and cannot prevent intentional disclosure. Removing the prefix for storage can evade recognition and undermines this aid.
- Provide usable tools and caution users rather than relying on a marker to make secret handling safe. Bearer-token possession can still enable misuse.
- RFC8959 is Informational. Section3 registers secret-token with provisional URI-scheme status; neither label is a guarantee of cryptographic strength or protocol adoption.
RFC8959 §§3–4. Lowercase advisory wording is preserved; no invented MUST-length, required scanner or encryption guarantee. No real secret input is requested.
Read the RFC section ↗