draft-hodges-webauthn-registries.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd" [
  <!ENTITY rfc2026 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml">
  <!ENTITY rfc5226 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>

<?xml-stylesheet type="text/xsl" href="http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>

<!-- 
  -00a: initial version based on RFC5988
  -00b: adapt 5988bis per mnot's suggestion:  draft-nottingham-rfc5988bis-01
        * 'attestation type' -> 'attestation format'
        * updated to latest extension id format, adjusted list of registered extensions to 
          match [WebAuthn] editors' draft.
  -00c: ?
  -00d: Let initial values be in the [WebAuthn] spec, rather than here.
-->

<rfc category="info" ipr="trust200902" docName="draft-hodges-webauthn-registries-01">
  <front>
    <title>Registries for Web Authentication (WebAuthn)</title>

    <author initials="J." surname="Hodges" fullname="Jeff Hodges">
      <organization>PayPal</organization>
      <address>
        <postal>
          <street>2211 North First Street</street>
          <city>San Jose</city>
          <region>California</region>
          <code>95131</code>
          <country>US</country>
        </postal>
        <email>Jeff.Hodges@PayPal.com</email>
	<uri>http://kingsmountain.com/people/Jeff.Hodges/</uri>
      </address>
    </author>
    <author fullname="Giridhar Mandyam" initials="G.D."
            surname="Mandyam">
      <organization>Qualcomm Technologies Inc.</organization>
      <address>
        <postal>
          <street>5775 Morehouse Drive</street>
          <!-- Reorder these if your country does things differently -->
          <city>San Diego</city>
          <region>California</region>
          <code>92121</code>
          <country>USA</country>
        </postal>
        <phone>+1 858 651 7200</phone>
        <email>mandyam@qti.qualcomm.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
      </address>
    </author>

    <date month="February" year="2018" />

    <area>Security</area>
    <workgroup>W3C WebAuthn Working Group</workgroup>

    <keyword>webauthn</keyword>
    <keyword>attestation</keyword>
    <keyword>extensions</keyword>
    <keyword>registry</keyword>

    <abstract>
      <t>
        This specification defines IANA registries for W3C Web Authentication
        attestation statement formats and extension identifiers.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
        This specification establishes IANA registries for W3C Web Authentication <xref
        target="WebAuthn"/> attestation statement formats and extension identifiers.
	The initial values for these registries are in the IANA Considerations
	section of the <xref target="WebAuthn"/> specification.
      </t>
    </section>


    <section title="WebAuthn Attestation Statement Format Identifier Registry"
      anchor="sctn-reg-new-attstn-format">

      <t>
        WebAuthn attestation statement format identifiers are strings whose semantic, syntactic,
        and string-matching criteria are specified in <xref target="WebAuthn"/>,
        along with the concepts of attestation and attestation statement formats.
      </t>
      <t>
        WebAuthn attestation statement formats are registered on the advice of a Designated Expert
        (appointed by the IESG or their delegate), with a Specification Required (per <xref
            target="RFC5226"/>).
      </t>
      <t>
        The Expert(s) will establish procedures for requesting registrations,
        and make them available from the registry page.
      </t>
      <t>
        Registration requests consist of at least the following information:
        <list style="symbols" >
          <t>
	    WebAuthn Attestation Statement Format Identifier:
	    This identifier  MUST be a maximum of 32 octets in length and MUST
	    consist only of printable USASCII characters, excluding backslash and doublequote.
	    This name is case sensitive.
	    Names may not match other registered names in a case-insensitive manner
	    unless the Designated Experts state that there is a compelling reason
	    to allow an exception.
	  </t>
          <t>
            Description: A relatively short description of the attestation
            format.
          </t>
          <t>
            Specification Document: Reference to the specification of the
            attestation statement format.
          </t>
          <t>Notes: [optional]</t>
        </list>
      </t>
      <t>
        The Expert(s) MAY define additional fields to be collected in the registry.
        Each attestation statement format identifier added to this registry MUST be unique
        amongst the set of registered attestation statement format identifiers.  The Experts(s) MAY
        also designate attestation statement formats as proprietary if they lack complete specifications,
        and will assign a prefix indicating as such to the identifier.
      </t>
      <t>
        Registrations MUST reference a freely available specification, e.g., as
        described in <xref target="RFC2026"/> Section 7.
      </t>
      <t>
        Note that WebAuthn attestation statement formats can be registered by third parties, if the
        Expert(s) determine that an unregistered attestation statement format is widely deployed and not
        likely to be registered in a timely manner.
      </t>
      <t>
        Decisions (or lack thereof) made by the Designated Expert can be
        first appealed to Application Area Directors (contactable using
        app-ads@tools.ietf.org email address or directly by looking up their
        email addresses on http://www.iesg.org/ website) and, if the
        appellant is not satisfied with the response, to the full IESG (using
        the iesg@iesg.org mailing list).
      </t>

      <t>
        <vspace blankLines="1" />
      </t>
    </section>

    <section title="WebAuthn Extension Identifier Registry"
      anchor="sctn-reg-new-extn-id">

      <t>
        WebAuthn extension identifiers are strings whose semantic, syntactic,
        and string-matching criteria are specified in <xref target="WebAuthn"/>.
      </t>
      <t>
        WebAuthn extension identifiers are registered on the advice of a Designated Expert
        (appointed by the IESG or their delegate), with a Specification Required (per <xref
            target="RFC5226"/>).
      </t>
      <t>
        The Expert(s) will establish procedures for requesting registrations,
        and make them available from the registry page.
      </t>
      <t>
        Registration requests consist of at least the following information:
        <list style="symbols" >
          <t>
	    WebAuthn Extension Identifier:
	    This identifier  MUST be a maximum of 32 octets in length and MUST
	    consist only of printable USASCII characters, excluding backslash and doublequote.
	    This name is case sensitive.
	    Names may not match other registered names in a case-insensitive manner
	    unless the Designated Experts state that there is a compelling reason
	    to allow an exception.
	  </t>
          <t>Description: A relatively short description of the extension.</t>
          <t>
            Specification Document: Reference to the specification of the
            extension.
          </t>
          <t>Notes: [optional]</t>
        </list>
      </t>

      <t>
        The Expert(s) MAY define additional fields to be collected in the registry.
        Each extension identifier added to this registry MUST be unique
        amongst the set of registered extension identifiers.
      </t>
      <t>
        Registrations MUST reference a freely available specification, e.g., as
        described in <xref target="RFC2026"/> Section 7.
      </t>
      <t>
        Note that WebAuthn extensions can be registered by third parties, if the Expert(s)
        determine that an unregistered extension is widely deployed and not likely to be
        registered in a timely manner.
      </t>
      <t>
        Decisions (or lack thereof) made by the Designated Expert can be
        first appealed to Application Area Directors (contactable using
        app-ads@tools.ietf.org email address or directly by looking up their
        email addresses on http://www.iesg.org/ website) and, if the
        appellant is not satisfied with the response, to the full IESG (using
        the iesg@iesg.org mailing list).
      </t>

    </section>

    <section title="IANA Considerations" anchor="sctn-iana-cons">

      <section title="WebAuthn Attestation Statement Format Identifier and Extension Identifiers Registries"
        anchor="sctn-attstn-extn-regs">

        <t>
          This specification establishes two registries:
          <list style="symbols">
            <t>
              the "WebAuthn Attestation Statement Format Identifier" registry; see <xref target="sctn-reg-new-attstn-format"/>.
            </t>
            <t>
              the "WebAuthn Extension Identifier" registry; see <xref target="sctn-reg-new-extn-id" />.
            </t>
          </list>
          For both registries, the Expert(s) and IANA will interact as outlined below:
        </t>
        <t>
          IANA will direct any incoming requests regarding the registry to the processes established
          by the Expert(s); typically, this will mean referring them to the registry HTML page.
        </t>
        <t>
          The Expert(s) will provide registry data to IANA in an agreed form (e.g., a specific XML
          format). IANA will publish:
          <list style="symbols">
            <t>The raw registry data</t>
            <t>The registry data, transformed into HTML</t>
            <t>The registry data in any alternative formats provided by the Expert(s)</t>
          </list>
        </t>
        <t>
          Each published document will be at a URL agreed to by IANA and the Expert(s) and IANA
          will set HTTP response headers on them as (reasonably) requested by the Expert(s).
        </t>
        <t>
          Additionally, the HTML generated by IANA will:
          <list style="symbols">
            <t>
              Take directions from the Expert(s) as to the content of the HTML page's introductory
              text and markup.
            </t>
            <t>
              Include a stable HTML fragment identifier for each registered attestation statement format or
              extension identifier.
            </t>
          </list>
        </t>
        <t>
          All registry data documents MUST include
          Simplified BSD License text as described in Section 4.e
          of the Trust Legal Provisions
          (<eref target="http://trustee.ietf.org/license-info" />).
        </t>

      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        See <xref target="WebAuthn"/> for relevant security considerations.
      </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        Thanks to Mark Nottingham
        for valuable comments and suggestions.
	Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area Director sponsorship of this specification.
      </t>
    </section>

    <section anchor="sctn-history" title="Document History">
      <t>[[ to be removed by the RFC Editor before publication as an RFC ]]</t>

      <t>
	-01
        <list style="symbols">
	  <t>
	    Refresh now that the WebAuthn Committee Recommendation (CR) draft is pending.
	  </t>
	</list>
      </t>

      <t>
	-00
        <list style="symbols">
	  <t>
	    Initial version.
	  </t>
	</list>
      </t>

    </section>

  </middle>


  <back>
    <references title="Normative References">
      &rfc2026;
      &rfc5226;

      <reference anchor="WebAuthn" target="https://w3c.github.io/webauthn/">
        <front>
          <title>Web Authentication: An API for accessing Public Key Credentials</title>
          <author initials="D." surname="Balfanz" fullname="Dirk Balfanz">
            <organization>Google</organization>
            <address>
              <email>balfanz@google.com</email>
            </address>
          </author>

          <author initials="A." surname="Czeskis" fullname="Alexei Czeskis">
            <organization>Google</organization>
            <address>
              <email>aczeskis@google.com</email>
            </address>
          </author>

          <author initials="J." surname="Hodges" fullname="Jeff Hodges">
            <organization>PayPal</organization>
            <address>
              <email>Jeff.Hodges@paypal.com</email>
            </address>
          </author>

          <author initials="J.C." surname="Jones" fullname="J.C. Jones">
            <organization>Mozilla</organization>
            <address>
              <email>jc@mozilla.com</email>
            </address>
          </author>

          <author initials="M.B." surname="Jones" fullname="Michael B. Jones">
            <organization>Microsoft</organization>
            <address>
              <email>mbj@microsoft.com</email>
	      <uri>http://self-issued.info/</uri>
            </address>
          </author>

          <author initials="A." surname="Kumar" fullname="Akshay Kumar">
            <organization>Microsoft</organization>
            <address>
              <email>akshayku@microsoft.com</email>
            </address>
          </author>

          <author initials="A." surname="Liao" fullname="Angelo Liao">
            <organization>Microsoft</organization>
            <address>
              <email>huliao@microsoft.com</email>
            </address>
          </author>

          <author initials="R." surname="Lindemann" fullname="Rolf Lindemann">
            <organization>Nok Nok Labs</organization>
            <address>
              <email>rolf@noknok.com</email>
            </address>
          </author>

          <author initials="E." surname="Lundberg" fullname="Emil Lundberg">
            <organization>Yubico</organization>
            <address>
              <email>emil@yubico.com</email>
            </address>
          </author>

          <date month="February" day="23" year="2018" />
        </front>
	<seriesInfo name="" value="Editors' Draft" />
        <seriesInfo name="World Wide Web Consortium (W3C)" value="Recommendation-track" />
        <format type="HTML" target="https://w3c.github.io/webauthn/" />
      </reference>

    </references>
  </back>
</rfc>