idnits 2.17.1 draft-hodges-webauthn-registries-09.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 abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2020) is 1434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 414 -- Looks like a reference, but probably isn't: '2' on line 417 -- Looks like a reference, but probably isn't: '3' on line 419 -- Looks like a reference, but probably isn't: '4' on line 422 -- Looks like a reference, but probably isn't: '5' on line 425 -- Looks like a reference, but probably isn't: '6' on line 428 -- Looks like a reference, but probably isn't: '7' on line 430 -- Looks like a reference, but probably isn't: '8' on line 433 -- Looks like a reference, but probably isn't: '9' on line 436 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 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: November 23, 2020 Qualcomm Technologies Inc. 6 M. Jones 7 Microsoft 8 May 22, 2020 10 Registries for Web Authentication (WebAuthn) 11 draft-hodges-webauthn-registries-09 13 Abstract 15 This specification defines IANA registries for W3C Web Authentication 16 attestation statement format identifiers and extension identifiers. 18 Note to Readers 20 _RFC EDITOR: please remove this section before publication_ 22 This is a work-in-progress. 24 The issues list can be found at https://github.com/w3c/webauthn/ 25 issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries [1]. 27 The most recent _published_ draft revision is at 28 https://tools.ietf.org/html/draft-hodges-webauthn-registries [2]. 30 The editors' draft is at https://github.com/w3c/webauthn/blob/master/ 31 draft-hodges-webauthn-registries.txt [3] 33 Changes in the editors' draft, both proposed and incorporated, are 34 listed at https://github.com/w3c/webauthn/ 35 pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries [4] 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on November 23, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 73 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 74 2.1. WebAuthn Attestation Statement Format Identifier Registry 3 75 2.1.1. Registering Attestation Statement Format Identifiers 4 76 2.1.2. Registration Request Processing . . . . . . . . . . . 5 77 2.1.3. Initial WebAuthn Attestation Statement Format 78 Identifier Registry Values . . . . . . . . . . . . . 5 79 2.2. WebAuthn Extension Identifier Registry . . . . . . . . . 5 80 2.2.1. Registering Extension Identifiers . . . . . . . . . . 6 81 2.2.2. Registration Request Processing . . . . . . . . . . . 6 82 2.2.3. Initial WebAuthn Extension Identifier Registry Values 7 83 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 5. Document History . . . . . . . . . . . . . . . . . . . . . . 7 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 This specification establishes IANA registries for W3C Web 94 Authentication [WebAuthn] attestation statement format identifiers 95 and extension identifiers. The initial values for these registries 96 are in the IANA Considerations section of the [WebAuthn] 97 specification. 99 1.1. Requirements Notation and Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. IANA Considerations 109 This specification establishes two registries: 111 o the "WebAuthn Attestation Statement Format Identifier" registry; 112 see Section 2.1. 113 o the "WebAuthn Extension Identifier" registry; see Section 2.2. 115 [[ Per discussions in an email thread between the authors and IANA ( 116 "[IANA #1154148]" ), it is requested that the registries be located 117 at . RFC Editor - please 118 delete this request after the registries have been created. ]] 120 Any additional processes established by the expert(s) after the 121 publication of this document will be recorded on the registry Web 122 page at the expert(s)' discretion. 124 2.1. WebAuthn Attestation Statement Format Identifier Registry 126 WebAuthn attestation statement format identifiers are strings whose 127 semantic, syntactic, and string-matching criteria are specified in 128 [WebAuthn] "Attestation Statement Format Identifiers" [5], along with 129 the concepts of attestation and attestation statement formats. 131 Registered attestation statement format identifiers are those that 132 have been added to the registry by following the procedure in 133 Section 2.1.1. 135 Each attestation statement format identifier added to this registry 136 MUST be unique amongst the set of registered attestation statement 137 format identifiers. 139 Registered attestation statement format identifiers MUST be a maximum 140 of 32 octets in length and MUST consist only of printable ASCII 141 [RFC20] characters, excluding backslash and doublequote, i.e., VCHAR 142 as defined in [RFC5234] but without %x22 and %x5c. Attestation 143 statement format identifiers are case sensitive and may not match 144 other registered identifiers in a case-insensitive manner unless the 145 Designated Experts determine that there is a compelling reason to 146 allow an exception. 148 2.1.1. Registering Attestation Statement Format Identifiers 150 WebAuthn attestation statement format identifiers are registered 151 using the Specification Required policy (see Section 4.6 of 152 [RFC8126]). 154 The WebAuthn attestation statement format identifiers registry is 155 located at https://www.iana.org/assignments/webauthn [6]. 156 Registration requests can be made by following the instructions 157 located there, or by sending an e-mail to the webauthn-reg- 158 review@ietf.org mailing list. 160 Registration requests consist of at least the following information: 162 o WebAuthn Attestation Statement Format Identifier: 163 An identifier meeting the requirements given above in Section 2.1. 164 o Description: 165 A relatively short description of the attestation format. 166 o Specification Document(s): 167 Reference to the document or documents that specify the 168 attestation statement format. 169 o Change Controller: 170 For Standards Track RFCs, list the "IESG". For others, give the 171 name of the responsible party. Other details (e.g., postal 172 address, email address, home page URI) may also be included. 173 o Notes: 174 [optional] 176 Registrations MUST reference a freely available, stable 177 specification, e.g., as described in Section 4.6 of [RFC8126]. This 178 specification MUST include security and privacy considerations 179 relevant to the attestation statement format. 181 Note that WebAuthn attestation statement format identifiers can be 182 registered by third parties (including the expert(s) themselves), if 183 the expert(s) determine that an unregistered attestation statement 184 format is widely deployed and not likely to be registered in a timely 185 manner otherwise. Such registrations still are subject to the 186 requirements defined, including the need to reference a 187 specification. 189 2.1.2. Registration Request Processing 191 As noted in Section 2.1.1, WebAuthn attestation statement format 192 identifiers are registered using the Specification Required policy. 194 The expert(s) will clearly identify any issues that cause a 195 registration to be refused, such as an incompletely specified 196 attestation format. 198 When a request is approved, the expert(s) will inform IANA, and the 199 registration will be processed. The IESG is the arbiter of any 200 objection. 202 2.1.3. Initial WebAuthn Attestation Statement Format Identifier 203 Registry Values 205 The initial values for the WebAuthn Attestation Statement Format 206 Identifier Registry are to be populated from the values listed in 207 "WebAuthn Attestation Statement Format Identifier Registrations" [7] 208 of [WebAuthn]. Also, the Change Controller entry to be used for each 209 of those registrations is: 211 o Change Controller: W3C Web Authentication Working Group - 212 public-webauthn@w3.org 214 2.2. WebAuthn Extension Identifier Registry 216 WebAuthn extension identifiers are strings whose semantic, syntactic, 217 and string-matching criteria are specified in [WebAuthn] "Extension 218 Identifiers" [8]. 220 Registered extension identifiers are those that have been added to 221 the registry by following the procedure in Section 2.2.1. 223 Each extension identifier added to this registry MUST be unique 224 amongst the set of registered extension identifiers. 226 Registered extension identifiers MUST be a maximum of 32 octets in 227 length and MUST consist only of printable ASCII characters, excluding 228 backslash and doublequote, i.e., VCHAR as defined in [RFC5234] but 229 without %x22 and %x5c. Extension identifiers are case sensitive and 230 may not match other registered identifiers in a case-insensitive 231 manner unless the Designated Experts determine that there is a 232 compelling reason to allow an exception. 234 2.2.1. Registering Extension Identifiers 236 WebAuthn extension identifiers registry are registered using the 237 Specification Required policy (see Section 4.6 of [RFC8126]). 239 The WebAuthn extension identifiers registry is located at 240 https://www.iana.org/assignments/webauthn. Registration requests can 241 be made by following the instructions located there, or by sending an 242 e-mail to the webauthn-reg-review@ietf.org mailing list. 244 Registration requests consist of at least the following information: 246 o WebAuthn Extension Identifier: 247 An identifier meeting the requirements given above in Section 2.2. 248 o Description: 249 A relatively short description of the extension. 250 o Specification Document(s): 251 Reference to the document or documents that specify the extension. 252 o Change Controller: 253 For Standards Track RFCs, list the "IESG". For others, give the 254 name of the responsible party. Other details (e.g., postal 255 address, email address, home page URI) may also be included. 256 o Notes: 257 [optional] 259 Registrations MUST reference a freely available, stable 260 specification, e.g., as described in Section 4.6 of [RFC8126]. This 261 specification MUST include security and privacy considerations 262 relevant to the extension. 264 Note that WebAuthn extensions can be registered by third parties 265 (including the expert(s) themselves), if the expert(s) determine that 266 an unregistered extension is widely deployed and not likely to be 267 registered in a timely manner otherwise. Such registrations still 268 are subject to the requirements defined, including the need to 269 reference a specification. 271 2.2.2. Registration Request Processing 273 As noted in Section 2.2.1, WebAuthn extension identifiers are 274 registered using the Specification Required policy. 276 The expert(s) will clearly identify any issues that cause a 277 registration to be refused, such as an incompletely specified 278 extension. 280 When a request is approved, the expert(s) will inform IANA, and the 281 registration will be processed. The IESG is the arbiter of any 282 objection. 284 2.2.3. Initial WebAuthn Extension Identifier Registry Values 286 The initial values for the WebAuthn Extension Identifier Registry are 287 to be populated from the values listed in "WebAuthn Extension 288 Identifier Registrations" [9] of [WebAuthn]. Also, the Change 289 Controller entry to be used for each of those registrations is: 291 o Change Controller: W3C Web Authentication Working Group - 292 public-webauthn@w3.org 294 3. Security Considerations 296 See [WebAuthn] for relevant security considerations. 298 4. Acknowledgements 300 Thanks to Mark Nottingham for valuable comments and suggestions. 301 Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area 302 Director sponsorship of this specification. Thanks to Amanda Baber, 303 Sarah Banks, Alissa Cooper, Roman Danyliw, Murray Kucherawy, Paul 304 Kyzivat, Barry Leiba, Hilarie Orman, Magnus Westerlund, and Robert 305 Wilton for their reviews. 307 5. Document History 309 [[ to be removed by the RFC Editor before publication as an RFC ]] 311 -09 313 o Added Change Controller fields to registries, per suggestion by 314 Magnus Westerlund. 315 o Applied editorial suggestions by Amanda Baber, Murray Kucherawy, 316 and Barry Leiba. 318 -08 320 o Addressed review feedback by Murray Kucherawy. 321 o Added BCP 14 Requirements Notation and Conventions section. 322 o Referenced RFC 20, which defines ASCII characters. 323 o Applied editorial cleanups. 325 -07 327 o Removed a duplicate URI listing pointed out by Hilarie Orman. 329 -06 331 o Addressed Gen-Art review comments by Paul Kyzivat by deleting text 332 about designated experts defining additional registry fields. 333 o Addressed Ops-Dir review comments by Sarah Banks by deleting text 334 that duplicated requirements already specified in RFC 8126. 335 o Addressed Security review comments by Hilarie Orman by deleting 336 unnecessary text about attestation statement formats lacking 337 complete specifications. 338 o Replaced uses of the URL https://www.w3.org/TR/webauthn/ with 339 https://www.w3.org/TR/2019/REC-webauthn-1-20190304/ so that the 340 reference remains stable after the level 2 WebAuthn specification 341 is published. 343 -05 345 o Updated to address the solicited IANA review comments, per 346 discussions in an email thread between the authors and IANA ( 347 "[IANA #1154148]" ). 349 -04 351 o Update per Benjamin Kaduk's further AD review: Remove 'final' wrt 352 IESG arbitrating objections; Add explicit requirement for 353 extension or attestation specs to include security and privacy 354 considerations. 355 o Update per IANA review: Move "IANA considerations section up in 356 doc to encompass (former) sections 2 and 3. 358 -03 360 o Update per Benjamin Kaduk's AD review. Align with RFC 8288, 361 rather than draft-nottingham-rfc5988bis. 363 -02 365 o Refresh now that the WebAuthn spec is at Recommendation (REC) 366 maturity level. 368 -01 370 o Refresh now that the WebAuthn Committee Recommendation (CR) draft 371 is pending. 373 -00 375 o Initial version, based on draft-nottingham-rfc5988bis. 377 6. References 379 6.1. Normative References 381 [RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, 382 RFC 20, October 1969, 383 . 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 391 Specifications: ABNF", STD 68, RFC 5234, 392 DOI 10.17487/RFC5234, January 2008, 393 . 395 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 396 Writing an IANA Considerations Section in RFCs", BCP 26, 397 RFC 8126, DOI 10.17487/RFC8126, June 2017, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 [WebAuthn] 405 Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 406 M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 407 "Web Authentication: An API for accessing Public Key 408 Credentials", World Wide Web Consortium 409 (W3C) Recommendation, March 2019, 410 . 412 6.2. URIs 414 [1] https://github.com/w3c/webauthn/ 415 issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries 417 [2] https://tools.ietf.org/html/draft-hodges-webauthn-registries 419 [3] https://github.com/w3c/webauthn/blob/master/draft-hodges- 420 webauthn-registries.txt 422 [4] https://github.com/w3c/webauthn/ 423 pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries 425 [5] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-attstn- 426 fmt-ids 428 [6] https://www.iana.org/assignments/webauthn 430 [7] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-att-fmt- 431 reg 433 [8] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn- 434 extension-id 436 [9] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn- 437 extensions-reg 439 Authors' Addresses 441 Jeff Hodges 442 Google 443 1600 Amphitheater Parkway 444 Mountain View, California 94043 445 US 447 Email: jdhodges@google.com 448 URI: https://kingsmountain.com/people/Jeff.Hodges/ 450 Giridhar Mandyam 451 Qualcomm Technologies Inc. 452 5775 Morehouse Drive 453 San Diego, California 92121 454 USA 456 Phone: +1 858 651 7200 457 Email: mandyam@qti.qualcomm.com 459 Michael B. Jones 460 Microsoft 462 Email: mbj@microsoft.com 463 URI: https://self-issued.info/