- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 29 Jul 2016 17:29:51 +0200
- To: "Mandyam, Giridhar" <mandyam@qti.qualcomm.com>
- Cc: "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C WebAuthn WG <public-webauthn@w3.org>
... and the Content Security Policy registry: http://www.iana.org/assignments/content-security-policy-directives/content-security-policy-directives.xhtml#directives which we helped Mike West set up using RFC7762. Cheers, > On 29 Jul 2016, at 5:26 PM, Mandyam, Giridhar <mandyam@qti.qualcomm.com> wrote: > > 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 > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 29 July 2016 15:30:21 UTC