The "secret-token" URI Scheme
draft-nottingham-how-did-that-get-into-the-repo-02

Section 1. Typo. s/ike CSRF/like CSRF/

Section 4.  Easy to find tokens will cut both ways.  This URI scheme would make it trivial (with likely an acceptable false positive rate) for a CI system to trigger on the presence of a token in a repo.  It would also be worth mentioning that adoption of this scheme would also further lower the bar for attackers when scanning for these tokens too – even less semantic parsing of source code would be required.

Section 4: "prevent accidental disclosure" seems a little strong. Perhaps "reduce the incidence of accidental disclosure" would be better.

Section 1

Per the comment in the shepherd writeup, RFC 6750 has a passable definition of "bearer
token".

Section 2

Perhaps an example Authorization header field (a la RFC 6750) would
demonstrate the "required for later access" aspect?

Section 4

   The token ABNF rule allows tokens as small as one character.  This is
   not recommended practice; applications should evaluate their
   requirements for entropy and issue tokens correspondingly.

I feel like we have some more concrete guidelines regarding token
entropy floating around.  BCP 106 is the obvious candidate, though its
emphasis is different than I would prefer.  I guess Section 8 is
tolerable.

   If it is difficult to correctly handle secret material, or unclear as
   to what the appropriate handling is, users might choose to obfuscate
   their secret tokens in order to evade detection (for example,
   removing the URI scheme for storage).  Clear guidelines and helpful
   tools are good mitigations here.

What would those "clear guidelines" be?

It's not clear to me whether or not this will truly help, but I don't see it causing any harm to the internet, and I think that it is good to try to mitigate against folk who either accidentally commit security tokens or deliberately commit them without any awareness of the consequences.