idnits 2.17.1 draft-hodges-webauthn-registries-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '... MUST be a maximum of 32 octets i...' RFC 2119 keyword, line 106: '... The Expert(s) MAY define additional...' RFC 2119 keyword, line 108: '... registry MUST be unique amongst the...' RFC 2119 keyword, line 109: '...rs. The Experts(s) MAY also designate...' RFC 2119 keyword, line 114: '... Registrations MUST reference a free...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 279 -- Looks like a reference, but probably isn't: '2' on line 281 -- Looks like a reference, but probably isn't: '3' on line 284 -- Looks like a reference, but probably isn't: '4' on line 286 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 W3C WebAuthn Working Group J. Hodges 3 Internet-Draft Google 4 Intended status: Informational G. Mandyam 5 Expires: September 12, 2019 Qualcomm Technologies Inc. 6 M. Jones 7 Microsoft 8 March 11, 2019 10 Registries for Web Authentication (WebAuthn) 11 draft-hodges-webauthn-registries-02 13 Abstract 15 This specification defines IANA registries for W3C Web Authentication 16 attestation statement format identifiers and extension identifiers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. WebAuthn Attestation Statement Format Identifier Registry . . 2 54 2.1. Initial WebAuthn Attestation Statement Format Identifier 55 Registry Values . . . . . . . . . . . . . . . . . . . . . 3 56 3. WebAuthn Extension Identifier Registry . . . . . . . . . . . 3 57 3.1. Initial WebAuthn Extension Identifier Registry Values . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. WebAuthn Attestation Statement Format Identifier and 60 Extension Identifiers Registries . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Document History . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 This specification establishes IANA registries for W3C Web 72 Authentication [WebAuthn] attestation statement format identifiers 73 and extension identifiers. The initial values for these registries 74 are in the IANA Considerations section of the [WebAuthn] 75 specification. 77 2. WebAuthn Attestation Statement Format Identifier Registry 79 WebAuthn attestation statement format identifiers are strings whose 80 semantic, syntactic, and string-matching criteria are specified in 81 [WebAuthn] Section 8.1 "Attestation Statement Format Identifiers" 82 [1], along with the concepts of attestation and attestation statement 83 formats. 85 WebAuthn attestation statement format identifiers are registered on 86 the advice of a Designated Expert (appointed by the IESG or their 87 delegate), with a Specification Required (per [RFC5226]). 89 The Expert(s) will establish procedures for requesting registrations, 90 and make them available from the registry page. 92 Registration requests consist of at least the following information: 94 o WebAuthn Attestation Statement Format Identifier: This identifier 95 MUST be a maximum of 32 octets in length and MUST consist only of 96 printable USASCII characters, excluding backslash and doublequote. 97 This name is case sensitive. Names may not match other registered 98 names in a case-insensitive manner unless the Designated Experts 99 state that there is a compelling reason to allow an exception. 100 o Description: A relatively short description of the attestation 101 format. 102 o Specification Document: Reference to the specification of the 103 attestation statement format. 104 o Notes: [optional] 106 The Expert(s) MAY define additional fields to be collected in the 107 registry. Each attestation statement format identifier added to this 108 registry MUST be unique amongst the set of registered attestation 109 statement format identifiers. The Experts(s) MAY also designate 110 attestation statement formats as proprietary if they lack complete 111 specifications, and will assign a prefix indicating as such to the 112 identifier. 114 Registrations MUST reference a freely available specification, e.g., 115 as described in [RFC2026] Section 7. 117 Note that WebAuthn attestation statement format identifiers can be 118 registered by third parties, if the Expert(s) determine that an 119 unregistered attestation statement format is widely deployed and not 120 likely to be registered in a timely manner. 122 Decisions (or lack thereof) made by the Designated Expert can be 123 first appealed to Application Area Directors (contactable using app- 124 ads@tools.ietf.org email address or directly by looking up their 125 email addresses on http://www.iesg.org/ website) and, if the 126 appellant is not satisfied with the response, to the full IESG (using 127 the iesg@iesg.org mailing list). 129 2.1. Initial WebAuthn Attestation Statement Format Identifier Registry 130 Values 132 The initial values for the WebAuthn Attestation Statement Format 133 Identifier Registry are to be populated from the values listed in 134 Section 11.1 "WebAuthn Attestation Statement Format Identifier 135 Registrations" [2] of [WebAuthn]. 137 3. WebAuthn Extension Identifier Registry 139 WebAuthn extension identifiers are strings whose semantic, syntactic, 140 and string-matching criteria are specified in [WebAuthn] Section 9.1 141 "Extension Identifiers" [3]. 143 WebAuthn extension identifiers are registered on the advice of a 144 Designated Expert (appointed by the IESG or their delegate), with a 145 Specification Required (per [RFC5226]). 147 The Expert(s) will establish procedures for requesting registrations, 148 and make them available from the registry page. 150 Registration requests consist of at least the following information: 152 o WebAuthn Extension Identifier: This identifier MUST be a maximum 153 of 32 octets in length and MUST consist only of printable USASCII 154 characters, excluding backslash and doublequote. This name is 155 case sensitive. Names may not match other registered names in a 156 case-insensitive manner unless the Designated Experts state that 157 there is a compelling reason to allow an exception. 158 o Description: A relatively short description of the extension. 159 o Specification Document: Reference to the specification of the 160 extension. 161 o Notes: [optional] 163 The Expert(s) MAY define additional fields to be collected in the 164 registry. Each extension identifier added to this registry MUST be 165 unique amongst the set of registered extension identifiers. 167 Registrations MUST reference a freely available specification, e.g., 168 as described in [RFC2026] Section 7. 170 Note that WebAuthn extensions can be registered by third parties, if 171 the Expert(s) determine that an unregistered extension is widely 172 deployed and not likely to be registered in a timely manner. 174 Decisions (or lack thereof) made by the Designated Expert can be 175 first appealed to Application Area Directors (contactable using app- 176 ads@tools.ietf.org email address or directly by looking up their 177 email addresses on http://www.iesg.org/ website) and, if the 178 appellant is not satisfied with the response, to the full IESG (using 179 the iesg@iesg.org mailing list). 181 3.1. Initial WebAuthn Extension Identifier Registry Values 183 The initial values for the WebAuthn Extension Identifier Registry are 184 to be populated from the values listed in Section 11.2 "WebAuthn 185 Extension Identifier Registrations" [4] of [WebAuthn]. 187 4. IANA Considerations 189 4.1. WebAuthn Attestation Statement Format Identifier and Extension 190 Identifiers Registries 192 This specification establishes two registries: 194 o the "WebAuthn Attestation Statement Format Identifier" registry; 195 see Section 2. 196 o the "WebAuthn Extension Identifier" registry; see Section 3. 198 For both registries, the Expert(s) and IANA will interact as outlined 199 below: 201 IANA will direct any incoming requests regarding the registry to the 202 processes established by the Expert(s); typically, this will mean 203 referring them to the registry HTML page. 205 The Expert(s) will provide registry data to IANA in an agreed form 206 (e.g., a specific XML format). IANA will publish: 208 o The raw registry data 209 o The registry data, transformed into HTML 210 o The registry data in any alternative formats provided by the 211 Expert(s) 213 Each published document will be at a URL agreed to by IANA and the 214 Expert(s) and IANA will set HTTP response headers on them as 215 (reasonably) requested by the Expert(s). 217 Additionally, the HTML generated by IANA will: 219 o Take directions from the Expert(s) as to the content of the HTML 220 page's introductory text and markup. 221 o Include a stable HTML fragment identifier for each registered 222 attestation statement format identifier or extension identifier. 224 All registry data documents MUST include Simplified BSD License text 225 as described in Section 4.e of the Trust Legal Provisions 226 (). 228 5. Security Considerations 230 See [WebAuthn] for relevant security considerations. 232 6. Acknowledgements 234 Thanks to Mark Nottingham for valuable comments and suggestions. 235 Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area 236 Director sponsorship of this specification. 238 7. Document History 240 [[ to be removed by the RFC Editor before publication as an RFC ]] 242 -02 244 o Refresh now that the WebAuthn spec is at Recommendation (REC) 245 maturity level. 247 -01 249 o Refresh now that the WebAuthn Committee Recommendation (CR) draft 250 is pending. 252 -00 254 o Initial version. 256 8. References 258 8.1. Normative References 260 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 261 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 262 . 264 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 265 IANA Considerations Section in RFCs", RFC 5226, 266 DOI 10.17487/RFC5226, May 2008, 267 . 269 [WebAuthn] 270 Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 271 M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 272 "Web Authentication: An API for accessing Public Key 273 Credentials", World Wide Web Consortium 274 (W3C) Recommendation, March 2019, 275 . 277 8.2. URIs 279 [1] https://www.w3.org/TR/webauthn/#sctn-attstn-fmt-ids 281 [2] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-att-fmt- 282 reg 284 [3] https://www.w3.org/TR/webauthn/#sctn-extension-id 286 [4] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn- 287 extensions-reg 289 Authors' Addresses 291 Jeff Hodges 292 Google 293 1600 Amphitheater Parkway 294 Mountain View, California 94043 295 US 297 Email: jdhodges@google.com 298 URI: http://kingsmountain.com/people/Jeff.Hodges/ 300 Giridhar Mandyam 301 Qualcomm Technologies Inc. 302 5775 Morehouse Drive 303 San Diego, California 92121 304 USA 306 Phone: +1 858 651 7200 307 Email: mandyam@qti.qualcomm.com 309 Michael B. Jones 310 Microsoft 312 Email: mbj@microsoft.com 313 URI: http://self-issued.info/