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

Document Type Active Internet-Draft (individual in art area)
Author Mark Nottingham 
Last updated 2020-11-17 (latest revision 2020-10-18)
Stream IETF
Intended RFC status Informational
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state (None)
Document shepherd Alexey Melnikov
Shepherd write-up Show (last changed 2020-02-12)
IESG IESG state RFC Ed Queue
Consensus Boilerplate Yes
Telechat date
Responsible AD Murray Kucherawy
Send notices to superuser@gmail.com, Alexey Melnikov <alexey.melnikov@isode.com>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state AUTH48
Details
Network Working Group                                      M. Nottingham
Internet-Draft                                           19 October 2020
Intended status: Informational                                          
Expires: 22 April 2021

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

Abstract

   This document registers the "secret-token" URI scheme, to aid in the
   identification of authentication tokens.

Note to Readers

   _RFC EDITOR: please remove this section before publication_

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/how-did-that-get-into-the-repo
   (https://github.com/mnot/I-D/labels/how-did-that-get-into-the-repo).

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/how-did-that-get-into-the-repo/
   (https://mnot.github.io/I-D/how-did-that-get-into-the-repo/).

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/how-did-that-get-into-the-repo (https://github.com/mnot/I-
   D/commits/gh-pages/how-did-that-get-into-the-repo).

   See also the draft's current status in the IETF datatracker, at
   https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get-
   into-the-repo/ (https://datatracker.ietf.org/doc/draft-nottingham-
   how-did-that-get-into-the-repo/).

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/.

Nottingham                Expires 22 April 2021                 [Page 1]
Internet-Draft         The secret-token URI Scheme          October 2020

   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 22 April 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  The secret-token URI scheme . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   It has become increasingly common to use bearer tokens as an
   authentication mechanism in various protocols.

   A bearer token is a security token with the property that any party
   in possession of the token (a "bearer") can use the token in any way
   that any other party in possession of it can.  Using a bearer token
   does not require a bearer to prove possession of cryptographic key
   material (proof-of-possession).

   Unfortunately, the number of security incidents involving accidental
   disclosure of these tokens has also increased.  For example, we now
   regularly hear about a developer committing an access token to a

Nottingham                Expires 22 April 2021                 [Page 2]
Internet-Draft         The secret-token URI Scheme          October 2020

   public source code repository, either because they didn't realise it
   was included in the committed code, or because they didn't realise
   the implications of its disclosure.

   This specification registers the "secret-token" URI scheme to aid
   prevention of such accidental disclosures.  When tokens are easier to
   unambiguously identify, they can trigger warnings in Continuous
   Integration systems, or be used in source code repositories
   themselves.  They can also be scanned for separately.
Show full document text