The "secret-token" URI Scheme
RFC 8959

Note: This ballot was opened for revision 01 and is now closed.

Murray Kucherawy Yes

Alvaro Retana No Objection

Benjamin Kaduk No Objection

Comment (2020-04-08 for -01)
Section 1

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

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

   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?

Erik Kline No Objection

Martin Vigoureux No Objection

Robert Wilton No Objection

Comment (2020-04-06 for -01)
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.

Roman Danyliw No Objection

Comment (2020-04-08 for -01)
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.

(Barry Leiba; former steering group member) Yes

Yes ( for -01)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-04-08 for -01)
Section 4: "prevent accidental disclosure" seems a little strong. Perhaps "reduce the incidence of accidental disclosure" would be better.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -01)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -01)
No email
send info