draft-hodges-webauthn-registries-00

Here's an initial cut at an internet-draft creating WebAuthn registries at
IANA. It is somewhat based upon RFC5988 by Mark Nottingham.

I spose we ought to use the issue tracker on this too so I created a new
issue label for it - "spec:webauthn-registries".

There are some issues noted inline, not all of which are submitted into
the issues list because there may be obvious resolutions based on prior
experience of reviewers. if not, then we can enter 'em and track 'em.

review encouraged, HTH,

=JeffH


Network Working Group                                          J. Hodges
Internet-Draft                                                    PayPal
Intended status: Informational                             June 13, 2016
Expires: December 15, 2016


                        The Profile URI Registry
                  draft-hodges-webauthn-registries-00

Abstract

   This specification defines IANA registries for W3C Web Authentication
   (WebAuthn) attestation types and extension identifiers.

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 http://datatracker.ietf.org/drafts/current/.

   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 December 15, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (http://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.  IANA Considerations
     2.1.  WebAuthn Attestation Types Registry
       2.1.1.  Registering New WebAuthn Attestation Types
       2.1.2.  Example WebAuthn Attestation Type Registration
               Request
       2.1.3.  Initial Registry Contents
     2.2.  WebAuthn Extension Identifiers Registry
       2.2.1.  Registering New WebAuthn Extension Identifiers
       2.2.2.  Example WebAuthn Extension Identifier Registration
               Request
       2.2.3.  Initial Registry Contents
   3.  Security Considerations
   4.  Change Log
   5.  Acknowledgements
   6.  Normative References
   Author's Address

1.  Introduction

   This specification defines IANA registries for W3C Web Authentication
   [WebAuthn] attestation types and extension identifiers, and supplies
   initial entries within each registry.

2.  IANA Considerations

2.1.  WebAuthn Attestation Types Registry

   This specification establishes the WebAuthn Attestation Types
   registry [WebAuthn].  The IANA registration policy is "Specification
   Required" per [RFC5226].  Instructions, and a request template, for a
   registrant to request the registration of a new WebAuthn Attestation
   Type are in Section 2.1.1.  An example registration request is given
   in Section 2.1.2.  The initial registry contents are given in
   Section 2.1.3.

   The underlying registry data (e.g., the XML file) must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions (<http://trustee.ietf.org/license-info>).

2.1.1.  Registering New WebAuthn Attestation Types

   WebAuthn Attestation Types are registered per the IANA registration
   policy of "Specification Required" [RFC5226], which implies use of a
   Designated Expert (appointed by the IESG (?) (W3C Team?) or their
   delegate).

   [[ISSUE: Who ought to appoint the DE and adjudicate any appeals?
   IESG (?) or W3C Team?  (appeals process is described below, presently
   in terms of IESG)]]

   WebAuthn attestation type identifiers are strings whose semantic,
   syntactic, uniqueness, and string-matching criteria are specified in
   [WebAuthn].

   [[ISSUES: <https://github.com/w3c/webauthn/issues/126>,
   <https://github.com/w3c/webauthn/issues/127>]]

   Registration requests consist of the completed registration template,
   given below, typically published in a W3C Recommendation, or RFC, or
   other Open Standard (in the sense described by [RFC2026], Section 7),
   and also submitted via email per the next paragraph.  However, to
   allow for the allocation of values prior to publication, the
   Designated Expert may approve registration once they are satisfied
   that a specification will be published.

   Registration requests should be sent to the <public-webauthn@w3.org>
   mailing list, marked clearly in the subject line (e.g., "NEW WEBAUTHN
   ATTESTATION TYPE: example" to register an "example" WebAuthn
   attestation type).

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the above mailing list and IANA.  Denials should include
   an explanation and, if applicable, suggestions as to how to make the
   request successful.

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

   IANA should only accept registry updates from the Designated
   Expert(s), and should direct all requests for registration to the
   above mailing list.

   The registration template is:

   o  WebAuthn Attestation Type: A unique string identifying the
      attestation type.
   o  Description: A relatively short description of the attestation
      type.
   o  Specification Document: Reference to the specification of the
      attestation type.
   o  Notes: [optional]


2.1.2.  Example WebAuthn Attestation Type Registration Request

   The following is an example registration request for a WebAuthn
   Attestation Type:

      This is a request to IANA to please register the "foobar" WebAuthn
      Attestation Type in the WebAuthn Attestation Types Registry
      according to [this document]:

         WebAuthn Attestation Type: FooBar
         Description: An example FooBar registration.
         Specification Document: <An unambiguous reference to [FooBar
         Specification]>


2.1.3.  Initial Registry Contents

   The WebAuthn Attestation Types registry's initial contents are:

      WebAuthn Attestation Type: packed
      Description: The "packed" attestation type is a WebAuthn-optimized
      format for attestation data.  It uses a very compact but still
      extensible encoding method.  This format is implementable by
      authenticators with limited resources (e.g., secure elements).
      Specification Document: [WebAuthn]


      WebAuthn Attestation Type: tpm
      Description: The TPM attestation type returns an attestation
      statement in the same format as the packed attestation type,
      although the the rawData and signature fields are computed
      differently.
      Specification Document: [WebAuthn]


      WebAuthn Attestation Type: android
      Description: Android-based, platform-provided authenticators may
      produce an attestation statement based on the Android SafetyNet
      API.
      Specification Document: [WebAuthn]


      WebAuthn Attestation Type: android2
      Description: Platform-provided authenticators based on Android
      versions "N", and later, may provide a "hardware attestation"
      statement.
      Specification Document: [AndroidHWAttstn]


2.2.  WebAuthn Extension Identifiers Registry

   This specification establishes the WebAuthn Extension Identifiers
   registry [WebAuthn].  The IANA registration policy is "Specification
   Required" per [RFC5226].  Instructions, and a request template, for a
   registrant to request the registration of a new WebAuthn Attestation
   Type are in Section 2.2.1.  An example registration request is given
   in Section 2.2.2.  The initial registry contents are given in
   Section 2.2.3.

   The underlying registry data (e.g., the XML file) must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions (<http://trustee.ietf.org/license-info>).

2.2.1.  Registering New WebAuthn Extension Identifiers

   WebAuthn Extension Identifiers are registered per the IANA
   registration policy of "Specification Required" [RFC5226], which
   implies use of a Designated Expert (appointed by the IESG (?) (W3C
   Team?) or their delegate).

   [[ISSUE: Who ought to appoint the DE and adjudicate any appeals?
   IESG (?) or W3C Team?  (appeals process is described below, presently
   in terms of IESG)]]

   WebAuthn Extension Identifiers are strings whose semantic, syntactic,
   uniqueness, and string-matching criteria are specified in [WebAuthn],
   specifically <https://www.w3.org/TR/webauthn/#extension-id>.

   [[ISSUE: <https://github.com/w3c/webauthn/issues/129>]]

   Registration requests consist of the completed registration template,
   given below, typically published in a W3C Recommendation, or RFC, or
   other Open Standard (in the sense described by [RFC2026], Section 7),
   and also submitted via email per the next paragraph.  However, to
   allow for the allocation of values prior to publication, the
   Designated Expert may approve registration once they are satisfied
   that a specification will be published.

   Registration requests should be sent to the <public-webauthn@w3.org>
   mailing list, marked clearly in the subject line (e.g., "NEW WEBAUTHN
   EXTENSION ID: example" to register an "example" WebAuthn extension
   identifier).

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the above mailing list and IANA.  Denials should include
   an explanation and, if applicable, suggestions as to how to make the
   request successful.

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

   IANA should only accept registry updates from the Designated
   Expert(s), and should direct all requests for registration to the
   above mailing list.

   The registration template is:

   o  WebAuthn Extension Identifier: A unique string identifying the
      extension.
   o  Description: A relatively short description of the extension.
   o  Specification Document: Reference to the specification of the
      extension.
   o  Notes: [optional]

2.2.2.  Example WebAuthn Extension Identifier Registration Request

   The following is an example registration request for a WebAuthn
   Extension Identifier:

      This is a request to IANA to please register the "BarFoo" WebAuthn
      Extension Identifier in the WebAuthn Extension Identifiers
      Registry according to [this document]:

         WebAuthn Extension Identifier: BarFoo
         Description: An example BarFoo registration.
         Specification Document: <An unambiguous reference to [BarFoo
         Specification]>


2.2.3.  Initial Registry Contents

   The WebAuthn Extension Identifiers registry's initial contents are:

      WebAuthn Extension Identifier: webauthn.txauth.simple
      Description: This signature extension allows for a simple form of
      transaction authorization.  A WebAuthn Relying Party can specify a
      prompt string, intended for display on a trusted device on the
      authenticator
      Specification Document: [WebAuthn]


      WebAuthn Extension Identifier: webauthn.txauth.generic
      Description: This generic txauth extension allows images to be
      used as prompts as well.  This allows authenticators without a
      font rendering engine to be used and also supports a richer visual
      appearance than accomplished with the webauthn.txauth.simple
      extension.
      Specification Document: [WebAuthn]


      WebAuthn Extension Identifier: webauthn.authn-sel
      Description: This registration extension allows a WebAuthn Relying
      Party to guide the selection of the authenticator that will be
      leveraged when creating the credential.  It is intended primarily
      for WebAuthn Relying Parties that wish to tightly control the
      experience around credential creation.
      Specification Document: [WebAuthn]


      WebAuthn Extension Identifier: webauthn.aaguid
      Description: This extension is added automatically by the
      authenticator.  This extension can be added to attestation
      statements and signatures.  A 128-bit Authenticator Attestation
      GUID encoded as a CBOR text string (major type 3).  This AAGUID is
      used to identify the Authenticator model (Authenticator
      Attestation GUID).
      Specification Document: [WebAuthn]


      WebAuthn Extension Identifier: webauthn.exts
      Description: The SupportedExtensions extension data is a list
      (CBOR array) of extension identifiers encoded as UTF-8 Strings.
      This extension is added automatically by the authenticator.  This
      extension can be added to attestation statements.
      Specification Document: [WebAuthn]


      WebAuthn Extension Identifier: webauthn.uvi
      Description: The user verification index (UVI) is a value uniquely
      identifying a user verification data record.  The UVI data can be
      used by servers to understand whether an authentication was
      authorized by the exact same biometric data as the initial key
      generation.  This allows the detection and prevention of "friendly
      fraud".
      Specification Document: [WebAuthn]


3.  Security Considerations

   [[there are likely some sec cons to discuss here.  TBD]]

4.  Change Log

   Note to RFC Editor: Please remove this section before publication.

   This is the initial -00 rev of this spec, hence no changes to log
   here at this time.

5.  Acknowledgements

   Thanks to <fill-in here> for valuable comments and suggestions.

6.  Normative References

   [AndroidHWAttstn]
              Google, "Android Hardware Attestation", Andorid Developers
              Reference  , 2016,
              <https://developer.android.com/reference/android/
              security/>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <http://www.rfc-editor.org/info/rfc2026>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [WebAuthn]
              Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A.,
              Birgisson, A., Hodges, J., Jones, M., and R. Lindemann,
              "Web Authentication: An API for accessing Scoped
              Credentials", World Wide Web Consortium FPWD, May 2016,
              <https://www.w3.org/TR/webauthn/>.

Author's Address

   Jeff Hodges
   PayPal
   2211 North First Street
   San Jose, California  95131
   US

   Email: Jeff.Hodges@PayPal.com

Received on Monday, 13 June 2016 18:30:50 UTC