Re: draft-hodges-webauthn-registries-00

Hey,

A few notes below.

> On 14 Jun 2016, at 4:30 AM, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
> 
> 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)]]

AUIU the IESG officially appoints all DEs, but the registry can ask them to consult with a community -- e.g., the W3C -- to find suitable candidates. In practice, they'll be very grateful for the help.


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

It's strongly encouraged to explicitly reference one of the registration policies in RFC5226 section 4.1 by name.

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

FWIW -- I kind of wish you hadn't take 5988 as a starting point; in practice, we've found that to be overly bureaucratic and over-specified. I've stated a 5988bis; see:
  https://mnot.github.io/I-D/rfc5988bis/#link-relation-type-registry





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

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 19 June 2016 01:26:55 UTC