idnits 2.17.1 draft-hodges-webauthn-registries-05.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. ** 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 135: '... MUST be unique amongst the set of r...' RFC 2119 keyword, line 136: '... The Experts(s) MAY also designate at...' RFC 2119 keyword, line 141: '...t format identifiers MUST be a maximum...' RFC 2119 keyword, line 142: '...ts in length and MUST consist only of ...' RFC 2119 keyword, line 176: '... 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 6, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 355 -- Looks like a reference, but probably isn't: '2' on line 358 -- Looks like a reference, but probably isn't: '3' on line 360 -- Looks like a reference, but probably isn't: '4' on line 363 -- Looks like a reference, but probably isn't: '5' on line 366 -- Looks like a reference, but probably isn't: '6' on line 368 -- Looks like a reference, but probably isn't: '7' on line 370 -- Looks like a reference, but probably isn't: '8' on line 372 -- Looks like a reference, but probably isn't: '9' on line 374 -- Looks like a reference, but probably isn't: '10' on line 376 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 11 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 7, 2020 Qualcomm Technologies Inc. 6 M. Jones 7 Microsoft 8 March 6, 2020 10 Registries for Web Authentication (WebAuthn) 11 draft-hodges-webauthn-registries-05 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 September 7, 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 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. WebAuthn Attestation Statement Format Identifier Registry 3 74 2.1.1. Registering Attestation Statement Format Identifiers 4 75 2.1.2. Registration Request Processing . . . . . . . . . . . 4 76 2.1.3. Initial WebAuthn Attestation Statement Format 77 Identifier Registry Values . . . . . . . . . . . . . 5 78 2.2. WebAuthn Extension Identifier Registry . . . . . . . . . 5 79 2.2.1. Registering Extension Identifiers . . . . . . . . . . 5 80 2.2.2. Registration Request Processing . . . . . . . . . . . 6 81 2.2.3. Initial WebAuthn Extension Identifier Registry Values 6 82 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 83 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 5. Document History . . . . . . . . . . . . . . . . . . . . . . 7 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 This specification establishes IANA registries for W3C Web 93 Authentication [WebAuthn] attestation statement format identifiers 94 and extension identifiers. The initial values for these registries 95 are in the IANA Considerations section of the [WebAuthn] 96 specification. 98 2. IANA Considerations 100 This specification establishes two registries: 102 o the "WebAuthn Attestation Statement Format Identifier" registry; 103 see Section 2.1. 104 o the "WebAuthn Extension Identifier" registry; see Section 2.2. 106 [[ Per discussions in an email thread between the authors and IANA ( 107 "[IANA #1154148]" ), it is requested that the registries be located 108 at . RFC Editor - please 109 delete this request after the registries have been created. ]] 111 For both registries, the expert(s) and IANA will interact as outlined 112 below: 114 IANA will direct any incoming requests regarding either of these 115 registries to this document and, if defined, the processes 116 established by the expert(s); typically, this will mean referring 117 them to the registry Web page. 119 Note that the expert(s) are allowed (as per Section 2.1.1 and 120 Section 2.2.1) to define additional fields to be collected in the 121 registry. 123 2.1. WebAuthn Attestation Statement Format Identifier Registry 125 WebAuthn attestation statement format identifiers are strings whose 126 semantic, syntactic, and string-matching criteria are specified in 127 [WebAuthn] "Attestation Statement Format Identifiers" [5], along with 128 the concepts of attestation and attestation statement formats. 130 Registered attestation statement format identifiers are those that 131 have been added to the registry by following the procedure in 132 Section 2.1.1. 134 Each attestation statement format identifier added to this registry 135 MUST be unique amongst the set of registered attestation statement 136 format identifiers. The Experts(s) MAY also designate attestation 137 statement formats as proprietary if they lack complete 138 specifications, and will assign a prefix indicating as such to the 139 identifier. 141 Registered attestation statement format identifiers MUST be a maximum 142 of 32 octets in length and MUST consist only of printable USASCII 143 characters, excluding backslash and doublequote, i.e., VCHAR as 144 defined in [RFC5234] but without %x22 and %x5c. Attestation 145 statement format identifiers are case sensitive. Attestation 146 statement format identifiers may not match other registered 147 identifiers in a case-insensitive manner unless the Designated 148 Experts determine that there is a compelling reason to allow an 149 exception. 151 2.1.1. Registering Attestation Statement Format Identifiers 153 WebAuthn attestation statement format identifiers are registered 154 using the Specification Required policy (see Section 4.6 of 155 [RFC8126]), which implies review and approval by a designated expert. 157 The WebAuthn attestation statement format identifiers registry is 158 located at https://www.iana.org/assignments/webauthn [6]. 159 Registration requests can be made by following the instructions 160 located there, or by sending an e-mail to the webauthn-reg- 161 review@ietf.org mailing list. 163 Registration requests consist of at least the following information: 165 o *WebAuthn Attestation Statement Format Identifier*: An identifier 166 meeting the requirements given above in Section 2.1. 167 o *Description*: A relatively short description of the attestation 168 format. 169 o *Reference*: Reference to the specification of the attestation 170 statement format. 171 o Notes: [optional] 173 The expert(s) can define additional fields to be collected in the 174 registry. 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, 193 implying review and approval by a designated expert. 195 The expert(s) will clearly identify any issues which cause a 196 registration to be refused. 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]. 210 2.2. WebAuthn Extension Identifier Registry 212 WebAuthn extension identifiers are strings whose semantic, syntactic, 213 and string-matching criteria are specified in [WebAuthn] "Extension 214 Identifiers" [8]. 216 Registered extension identifiers are those that have been added to 217 the registry by following the procedure in Section 2.2.1. 219 Each extension identifier added to this registry MUST be unique 220 amongst the set of registered extension identifiers. 222 Registered extension identifiers MUST be a maximum of 32 octets in 223 length and MUST consist only of printable USASCII characters, 224 excluding backslash and doublequote, i.e., VCHAR as defined in 225 [RFC5234] but without %x22 and %x5c. Extension identifiers are case 226 sensitive. Extension identifiers may not match other registered 227 names in a case-insensitive manner unless the Designated Experts 228 determine that there is a compelling reason to allow an exception. 230 2.2.1. Registering Extension Identifiers 232 WebAuthn extension identifiers registry are registered using the 233 Specification Required policy (see Section 4.6 of [RFC8126]), which 234 implies review and approval by a designated expert. 236 The WebAuthn extension identifiers registry is located at 237 https://www.iana.org/assignments/webauthn [9]. Registration requests 238 can be made by following the instructions located there, or by 239 sending an e-mail to the webauthn-reg-review@ietf.org mailing list. 241 Registration requests consist of at least the following information: 243 o *WebAuthn Extension Identifier*: An identifier meeting the 244 requirements given above in Section 2.2. 245 o *Description*: A relatively short description of the extension. 246 o *Reference*: Reference to the specification of the extension. 247 o Notes: [optional] 249 The expert(s) can define additional fields to be collected in the 250 registry. 252 Registrations MUST reference a freely available, stable 253 specification, e.g., as described in Section 4.6 of [RFC8126]. This 254 specification MUST include security and privacy considerations 255 relevant to the extension. 257 Note that WebAuthn extensions can be registered by third parties 258 (including the expert(s) themselves), if the expert(s) determine that 259 an unregistered extension is widely deployed and not likely to be 260 registered in a timely manner otherwise. Such registrations still 261 are subject to the requirements defined, including the need to 262 reference a specification. 264 2.2.2. Registration Request Processing 266 As noted in Section 2.2.1, WebAuthn extension identifiers are 267 registered using the Specification Required policy, implying review 268 and approval by a designated expert. 270 The expert(s) will clearly identify any issues which cause a 271 registration to be refused. 273 When a request is approved, the expert(s) will inform IANA, and the 274 registration will be processed. The IESG is the arbiter of any 275 objection. 277 2.2.3. Initial WebAuthn Extension Identifier Registry Values 279 The initial values for the WebAuthn Extension Identifier Registry are 280 to be populated from the values listed in "WebAuthn Extension 281 Identifier Registrations" [10] of [WebAuthn]. 283 3. Security Considerations 285 See [WebAuthn] for relevant security considerations. 287 4. Acknowledgements 289 Thanks to Mark Nottingham for valuable comments and suggestions. 290 Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area 291 Director sponsorship of this specification. 293 5. Document History 295 [[ to be removed by the RFC Editor before publication as an RFC ]] 297 -05 299 o Updated to address the solicited IANA review comments, per 300 discussions in an email thread between the authors and IANA ( 301 "[IANA #1154148]" ). 303 -04 305 o Update per Benjamin Kaduk's further AD review: Remove 'final' wrt 306 IESG arbitrating objections; Add explicit requirement for 307 extension or attestation specs to include security and privacy 308 considerations. 309 o Update per IANA review: Move "IANA considerations section up in 310 doc to encompass (former) sections 2 and 3. 312 -03 314 o Update per Benjamin Kaduk's AD review. Align with RFC 8288, 315 rather than draft-nottingham-rfc5988bis. 317 -02 319 o Refresh now that the WebAuthn spec is at Recommendation (REC) 320 maturity level. 322 -01 324 o Refresh now that the WebAuthn Committee Recommendation (CR) draft 325 is pending. 327 -00 329 o Initial version, based on draft-nottingham-rfc5988bis. 331 6. References 333 6.1. Normative References 335 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 336 Specifications: ABNF", STD 68, RFC 5234, 337 DOI 10.17487/RFC5234, January 2008, 338 . 340 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 341 Writing an IANA Considerations Section in RFCs", BCP 26, 342 RFC 8126, DOI 10.17487/RFC8126, June 2017, 343 . 345 [WebAuthn] 346 Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 347 M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 348 "Web Authentication: An API for accessing Public Key 349 Credentials", World Wide Web Consortium 350 (W3C) Recommendation, March 2019, 351 . 353 6.2. URIs 355 [1] https://github.com/w3c/webauthn/ 356 issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries 358 [2] https://tools.ietf.org/html/draft-hodges-webauthn-registries 360 [3] https://github.com/w3c/webauthn/blob/master/draft-hodges- 361 webauthn-registries.txt 363 [4] https://github.com/w3c/webauthn/ 364 pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries 366 [5] https://www.w3.org/TR/webauthn/#sctn-attstn-fmt-ids 368 [6] https://www.iana.org/assignments/webauthn 370 [7] https://www.w3.org/TR/webauthn/#sctn-att-fmt-reg 372 [8] https://www.w3.org/TR/webauthn/#sctn-extension-id 374 [9] https://www.iana.org/assignments/webauthn 376 [10] https://www.w3.org/TR/webauthn/#sctn-extensions-reg 378 Authors' Addresses 380 Jeff Hodges 381 Google 382 1600 Amphitheater Parkway 383 Mountain View, California 94043 384 US 386 Email: jdhodges@google.com 387 URI: https://kingsmountain.com/people/Jeff.Hodges/ 389 Giridhar Mandyam 390 Qualcomm Technologies Inc. 391 5775 Morehouse Drive 392 San Diego, California 92121 393 USA 395 Phone: +1 858 651 7200 396 Email: mandyam@qti.qualcomm.com 398 Michael B. Jones 399 Microsoft 401 Email: mbj@microsoft.com 402 URI: https://self-issued.info/