Recognize an accidental secret
01A bearer token lets any holder use it without proving possession of a separate cryptographic key. A recognizable URI prefix helps tools notice generated API keys before an accidental disclosure.
The example repository recognizes the marker and refuses this commit. Detection depends on the tool and configuration; there is no guarantee that all leaks are caught.
Source for this drawing: RFC 8959 · Read RFC section 1 ↗
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 scheme identifies generated secrets such as API keys. It is not intended for controlled ephemeral uses such as CSRF tokens.
- The scheme identifies generated secrets such as API keys. It is not intended for controlled ephemeral uses such as CSRF tokens.
- A repository or CI system can warn about or refuse a commit containing these URIs. This is an example policy, not a mandatory scanner protocol or guaranteed detection.
- The prefix marks sensitive material; it does not hide the token or make its holder trustworthy.
RFC8959 §1 supplies the repository example and bearer definition. No actual secret, repository upload or scanner is used here.
Read the RFC section ↗