- From: Mandyam, Giridhar <mandyam@qti.qualcomm.com>
- Date: Fri, 29 Jul 2016 15:26:14 +0000
- To: "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C WebAuthn WG <public-webauthn@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>
Many thanks to Jeff for this cut at the registry. Have a broader question - should this be done at IETF or can it be done as a W3C-published registry? We have some precedent for W3C-published registries, more recently with the MSE byte stream registry (https://w3c.github.io/media-source/byte-stream-format-registry.html) and EME registry (https://www.w3.org/TR/eme-stream-registry/). -Giri -----Original Message----- From: Hodges, Jeff [mailto:jeff.hodges@paypal.com] Sent: Monday, June 13, 2016 11:30 AM To: W3C WebAuthn WG <public-webauthn@w3.org> Cc: Mark Nottingham <mnot@mnot.net> Subject: 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 Friday, 29 July 2016 15:26:47 UTC