<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-linuxgemini-otpauth-uri-00" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="otpauth URI spec">Usage specification of the otpauth URI format for TOTP and HOTP token generators</title><seriesInfo value="draft-linuxgemini-otpauth-uri-00" stream="IETF" status="informational" name="RFC"></seriesInfo>
<author initials="I. Y." surname="Eroglu" fullname="Ilteris Yagiztegin Eroglu"><organization>independent</organization><address><postal><street></street>
<city>Ankara</city>
<country>Turkey</country>
</postal><email>ietf@linuxgemini.space</email>
</address></author><date/>
<area>Internet</area>
<workgroup></workgroup>
<keyword>internet</keyword>
<keyword>internet security</keyword>
<keyword>otpauth</keyword>
<keyword>totp</keyword>
<keyword>hotp</keyword>

<abstract>
<t>This document describes a foundational schema for the otpauth URI,
utilized by TOTP (and/or HOTP) based authenticators.</t>
</abstract>

</front>

<middle>

<section anchor="Discussion"><name>Discussion</name>
<t>This note is to be removed before publishing as an RFC.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/linuxgemini/otpauth-spec-draft">https://github.com/linuxgemini/otpauth-spec-draft</eref>.</t>
</section>

<section anchor="Introduction"><name>Introduction</name>
<t>The otpauth URI is used for easy addition of accounts to TOTP (and/or HOTP)
authenticators with various options
<xref target="Google.Authenticator.OSS.Wiki.Key.Format"></xref>.</t>
<t>Although available as a provisional scheme at IANA
<xref target="IANA.URISchemes.Prov.otpauth"></xref>, there are many divisions of the usage
specification per authenticator hardware and software <xref target="Edent.Blog.Post"></xref>.</t>
<t>This document aims to provide foundational boundaries for the URI format
and standardize the secret sharing of OTP tokens.</t>

<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when, they
appear in all capitals, as shown here.</t>
<t>This specification uses the Augmented Backus-Naur Form (ABNF) notation
of <xref target="RFC5234"></xref>.</t>
<t>This specification uses the terms &quot;TOTP&quot; defined by <xref target="RFC6238"></xref> and &quot;HOTP&quot;
defined by <xref target="RFC4226"></xref>. Both RFCs also mention &quot;secret&quot;, &quot;issuer&quot; and
&quot;account&quot;.</t>
<t>The term &quot;URI&quot; is imported from <xref target="RFC3986"></xref>. Mentions of &quot;query string&quot; in
this document references the &quot;Query&quot; parameter (in section 3.4) of this RFC.</t>
<t>The Base16, Base32, and Base64 Data Encodings mentioned here are imported
from <xref target="RFC4648"></xref> with the same name.</t>
</section>
</section>

<section anchor="syntax"><name>Syntax</name>
<t>The URI MUST be formatted like below:</t>

<artwork>otpauth://TYPE/LABEL?PARAMETERS
</artwork>
<t>An approximate ABNF representation of this is like below:</t>

<artwork>otpauth-uri    = &quot;otpauth://&quot; uri-type &quot;/&quot; uri-label &quot;?&quot; uri-parameters
uri-type       = &quot;totp&quot; / &quot;hotp&quot;
uri-label      = *VCHAR
uri-parameters = &quot;secret=&quot; *base-32 [ *uri-opt-parameters ]

uri-opt-parameters =  (&quot;&amp;algorithm=&quot; otp-algorithm)
uri-opt-parameters =/ (&quot;&amp;digits=&quot; otp-digits)
uri-opt-parameters =/ (&quot;&amp;counter=&quot; *DIGIT) / (&quot;&amp;period=&quot; *DIGIT)
uri-opt-parameters =/ (&quot;&amp;issuer=&quot; *VCHAR) / (&quot;&amp;&quot; *VCHAR &quot;=&quot; *VCHAR)
                        ; Please refer to RFC3986 for handling
                        ; complex names

otp-algorithm = &quot;SHA1&quot; / &quot;SHA256&quot; / &quot;SHA512&quot;

otp-digits    = %x36-38
                ; 6-8

base-32 = %x41-5A / %x32-37
                ; A-Z2-7
DIGIT   = %x30-39
                ; 0-9
VCHAR   = %x21-7E
                ; visible (printing) characters
</artwork>

<section anchor="type-entry-required"><name><tt>TYPE</tt> entry (REQUIRED)</name>
<t>The type entry MUST be one of <tt>totp</tt> or <tt>hotp</tt>, depending on the OTP type.</t>
</section>

<section anchor="label-entry-required"><name><tt>LABEL</tt> entry (REQUIRED)</name>
<t>The label entry MUST be an identifier representing the user. For example,
can be an username, nickname or a person's name.</t>
<t>Although the Authenticator Team at Google recommends including the secret
issuer to be prepended to the label with the colon character (<tt>:</tt> or <tt>%3A</tt>)
as a seperator in <xref target="Google.Authenticator.OSS.Wiki.Key.Format"></xref>, the authors
of this document believe that the issuer should only be appended as a
seperate parameter(see next division).</t>
</section>

<section anchor="parameters-entry-required"><name><tt>PARAMETERS</tt> entry (REQUIRED)</name>
<t>This entry is an URI query string. Each parameter MUST be seperated by the
<tt>&amp;</tt> character and SHOULD BE &quot;URI Safe&quot; (see section 2.2. Reserved
Characters in <xref target="RFC3986"></xref>).</t>
<t>The following parameters SHOULD BE included:</t>

<section anchor="secret-parameter-required"><name><tt>secret</tt> parameter (REQUIRED)</name>
<t>The secret of the OTP MUST be provided within this parameter. The secret
MUST be encoded in Base32. The padding specified in <xref target="RFC4648"></xref>
section 2.2 is not required and SHOULD BE omitted.</t>
<t>For example:</t>

<artwork>otpauth://totp/ietfuser?secret=NBSWY3DPFQQHO33SNRSAU
</artwork>
</section>

<section anchor="algorithm-parameter-optional"><name><tt>algorithm</tt> parameter (OPTIONAL)</name>
<t>The algorithm used for TOTP or HOTP tokens SHOULD BE provided
in this parameter. When not provided, <tt>SHA1</tt> is assumed by default.</t>
<t>The ABNF representation is defined below:</t>

<artwork>otp-algorithm   = &quot;SHA1&quot; / &quot;SHA256&quot; / &quot;SHA512&quot;
</artwork>
<t>Some authenticators at the time writing of this document ignore this
parameter, the authors of this document believes that this parameter
MUST be supported in all cases.</t>
</section>

<section anchor="digits-parameter-optional"><name><tt>digits</tt> parameter (OPTIONAL)</name>
<t>The amount of digits to be outputted for TOTP or HOTP tokens
SHOULD BE provided in this parameter. This value MUST be
between 6 and 8. When not provided, 6 digits is assumed by default.</t>
<t>Some authenticators at the time writing of this document ignore this
parameter, the authors of this document believes that this parameter
MUST be supported in all cases.</t>
</section>

<section anchor="counter-parameter-optional-required-if-hotp"><name><tt>counter</tt> parameter (OPTIONAL, REQUIRED if HOTP)</name>
<t>The provisioning counter for TOTP or HOTP tokens SHOULD BE provided
in this parameter.</t>
<t>This parameter is required if the token type is HOTP.</t>
</section>

<section anchor="period-parameter-optional"><name><tt>period</tt> parameter (OPTIONAL)</name>
<t>The refresh period (in seconds) for TOTP or HOTP tokens SHOULD BE provided
in this parameter. When not provided, 30 seconds is assumed by default.</t>
<t>Some authenticators at the time writing of this document ignore this
parameter, the authors of this document believes that this parameter
MUST be supported in all cases.</t>
</section>

<section anchor="issuer-parameter-optional"><name><tt>issuer</tt> parameter (OPTIONAL)</name>
<t>The issuer name of TOTP or HOTP tokens SHOULD BE provided
in this parameter.</t>
</section>

<section anchor="other-parameters-optional"><name>Other parameters (OPTIONAL)</name>
<t>Vendors MAY include other parameters in their issued otpauth URIs.
These parameters are OPTIONAL for the function of TOTP or HOTP
tokens and not necessary to be included in this document.</t>
</section>
</section>
</section>

<section anchor="Examples"><name>Examples</name>

<artwork>otpauth://totp/ietfuser?secret=NBSWY3DP

otpauth://hotp/13tfus3r?secret=NBSWY3DP&amp;counter=192

otpauth://totp/big?issuer=why&amp;secret=NBSWY3DP&amp;period=5&amp;algorithm=SHA256
</artwork>
</section>

<section anchor="SecurityConsiderations"><name>Security Considerations</name>
<t>This URI format does not in itself pose a security threat. However,
the Security Considerations of <xref target="RFC3986"></xref> SHOULD BE followed.</t>
</section>

<section anchor="IANAConsiderations"><name>IANA Considerations</name>
<t>This format is already available as a provisional entry
<xref target="IANA.URISchemes.Prov.otpauth"></xref>. IANA is asked to change
the provisional URI scheme to reference [[this RFC]].</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4226.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6238.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="Edent.Blog.Post" target="https://shkspr.mobi/blog/2022/05/why-is-there-no-formal-specification-for-otpauth-urls/">
  <front>
    <title>Why is there no formal specification for otpauth URls?</title>
    <author></author>
  </front>
</reference>
<reference anchor="Edent.Mastodon.Post" target="https://mastodon.social/@Edent/108266107975107228">
  <front>
    <title>Fediverse post for &#34;Why is there no formal specification for otpauth URls?&#34;</title>
    <author></author>
  </front>
</reference>
<reference anchor="Google.Authenticator.OSS.Wiki.Key.Format" target="https://github.com/google/google-authenticator/wiki/Key-Uri-Format">
  <front>
    <title>Google Authenticator Key Uri Format</title>
    <author>
      <organization>Google</organization>
    </author>
  </front>
</reference>
<reference anchor="IANA.URISchemes.Prov.otpauth" target="https://www.iana.org/assignments/uri-schemes/prov/otpauth">
  <front>
    <title>Provisional scheme for the otpauth URI</title>
    <author>
      <organization>IANA</organization>
    </author>
  </front>
</reference>
</references>

<section anchor="Acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank
Q Misell,
Terrence Eden,
The Google Authenticator Team at Google,
and others (please let us know, if you've been mistakenly omitted)
for their valuable input, feedback and general support of this work.</t>
<t>This document originated from discussions at the Fediverse initially
written by Terrence Eden <xref target="Edent.Mastodon.Post"></xref>.</t>
</section>

<section anchor="document-history"><name>Document History</name>
<t>[[ To be removed from the final specification ]]</t>
<t>-00</t>

<ul spacing="compact">
<li>first draft</li>
</ul>
</section>

</back>

</rfc>
