idnits 2.17.1 draft-hodges-webauthn-registries-03.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 112: '... MUST be unique amongst the set of r...' RFC 2119 keyword, line 113: '... The Experts(s) MAY also designate at...' RFC 2119 keyword, line 118: '...t format identifiers MUST be a maximum...' RFC 2119 keyword, line 119: '...ts in length and MUST consist only of ...' RFC 2119 keyword, line 154: '... Registrations MUST reference a free...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 18, 2019) is 1650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 341 -- Looks like a reference, but probably isn't: '2' on line 344 -- Looks like a reference, but probably isn't: '3' on line 346 -- Looks like a reference, but probably isn't: '4' on line 349 -- Looks like a reference, but probably isn't: '5' on line 352 -- Looks like a reference, but probably isn't: '6' on line 354 -- Looks like a reference, but probably isn't: '7' on line 356 -- Looks like a reference, but probably isn't: '8' on line 358 -- Looks like a reference, but probably isn't: '9' on line 360 -- Looks like a reference, but probably isn't: '10' on line 362 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: April 20, 2020 Qualcomm Technologies Inc. 6 M. Jones 7 Microsoft 8 Oct 18, 2019 10 Registries for Web Authentication (WebAuthn) 11 draft-hodges-webauthn-registries-03 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 April 20, 2020. 54 Copyright Notice 56 Copyright (c) 2019 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. WebAuthn Attestation Statement Format Identifier Registry . . 3 73 2.1. Registering Attestation Statement Format Identifiers . . 3 74 2.2. Registration Request Processing . . . . . . . . . . . . . 4 75 2.3. Initial WebAuthn Attestation Statement Format Identifier 76 Registry Values . . . . . . . . . . . . . . . . . . . . . 4 77 3. WebAuthn Extension Identifier Registry . . . . . . . . . . . 4 78 3.1. Registering Extension Identifiers . . . . . . . . . . . . 5 79 3.2. Registration Request Processing . . . . . . . . . . . . . 6 80 3.3. Initial WebAuthn Extension Identifier Registry Values . . 6 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 4.1. WebAuthn Attestation Statement Format Identifier and 83 Extension Identifiers Registries . . . . . . . . . . . . 6 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 86 7. Document History . . . . . . . . . . . . . . . . . . . . . . 7 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 89 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Introduction 94 This specification establishes IANA registries for W3C Web 95 Authentication [WebAuthn] attestation statement format identifiers 96 and extension identifiers. The initial values for these registries 97 are in the IANA Considerations section of the [WebAuthn] 98 specification. 100 2. WebAuthn Attestation Statement Format Identifier Registry 102 WebAuthn attestation statement format identifiers are strings whose 103 semantic, syntactic, and string-matching criteria are specified in 104 [WebAuthn] "Attestation Statement Format Identifiers" [5], along with 105 the concepts of attestation and attestation statement formats. 107 Registered attestation statement format identifiers are those that 108 have been added to the registry by following the procedure in 109 Section 2.1. 111 Each attestation statement format identifier added to this registry 112 MUST be unique amongst the set of registered attestation statement 113 format identifiers. The Experts(s) MAY also designate attestation 114 statement formats as proprietary if they lack complete 115 specifications, and will assign a prefix indicating as such to the 116 identifier. 118 Registered attestation statement format identifiers MUST be a maximum 119 of 32 octets in length and MUST consist only of printable USASCII 120 characters, excluding backslash and doublequote, i.e., VCHAR as 121 defined in [RFC5234] but without %x22 and %x5c. Attestation 122 statement format identifiers are case sensitive. Attestation 123 statement format identifiers may not match other registered 124 identifiers in a case-insensitive manner unless the Designated 125 Experts determine that there is a compelling reason to allow an 126 exception. 128 2.1. Registering Attestation Statement Format Identifiers 130 WebAuthn attestation statement format identifiers are registered 131 using the Specification Required policy (see Section 4.6 of 132 [RFC8126]), which implies review and approval by a designated expert. 134 The WebAuthn attestation statement format identifiers registry is 135 located at https://www.iana.org/assignments/(fill-in-here-per-IANA)/ 136 [6]. Registration requests can be made by following the instructions 137 located there, or by sending an e-mail to the "public- 138 webauthn@w3.org" mailing list. 140 Registration requests consist of at least the following information: 142 o *WebAuthn Attestation Statement Format Identifier*: An identifier 143 meeting the requirements given above in Section 2. 145 o *Description*: A relatively short description of the attestation 146 format. 147 o *Reference*: Reference to the specification of the attestation 148 statement format. 149 o Notes: [optional] 151 The expert(s) can define additional fields to be collected in the 152 registry. 154 Registrations MUST reference a freely available, stable 155 specification, e.g., as described in Section 7 of [RFC2026]. 157 Note that WebAuthn attestation statement format identifiers can be 158 registered by third parties (including the expert(s) themselves), if 159 the expert(s) determine that an unregistered attestation statement 160 format is widely deployed and not likely to be registered in a timely 161 manner otherwise. Such registrations still are subject to the 162 requirements defined, including the need to reference a 163 specification. 165 2.2. Registration Request Processing 167 As noted in Section 2.1, WebAuthn attestation statement format 168 identifiers are registered using the Specification Required policy, 169 implying review and approval by a designated expert. 171 The expert(s) will clearly identify any issues which cause a 172 registration to be refused. 174 When a request is approved, the expert(s) will inform IANA, and the 175 registration will be processed. The IESG is the final arbiter of any 176 objection. 178 2.3. Initial WebAuthn Attestation Statement Format Identifier Registry 179 Values 181 The initial values for the WebAuthn Attestation Statement Format 182 Identifier Registry are to be populated from the values listed in 183 "WebAuthn Attestation Statement Format Identifier Registrations" [7] 184 of [WebAuthn]. 186 3. WebAuthn Extension Identifier Registry 188 WebAuthn extension identifiers are strings whose semantic, syntactic, 189 and string-matching criteria are specified in [WebAuthn] "Extension 190 Identifiers" [8]. 192 Registered extension identifiers are those that have been added to 193 the registry by following the procedure in Section 3.1. 195 Each extension identifier added to this registry MUST be unique 196 amongst the set of registered extension identifiers. 198 Registered extension identifiers MUST be a maximum of 32 octets in 199 length and MUST consist only of printable USASCII characters, 200 excluding backslash and doublequote, i.e., VCHAR as defined in 201 [RFC5234] but without %x22 and %x5c. Extension identifiers are case 202 sensitive. Extension identifiers may not match other registered 203 names in a case-insensitive manner unless the Designated Experts 204 determine that there is a compelling reason to allow an exception. 206 3.1. Registering Extension Identifiers 208 WebAuthn extension identifiers registry are registered using the 209 Specification Required policy (see Section 4.6 of [RFC8126]), which 210 implies review and approval by a designated expert. 212 The WebAuthn extension identifiers registry is located at 213 https://www.iana.org/assignments/(fill-in-here-per-IANA)/ [9]. 214 Registration requests can be made by following the instructions 215 located there, or by sending an e-mail to the "public- 216 webauthn@w3.org" mailing list. 218 Registration requests consist of at least the following information: 220 o *WebAuthn Extension Identifier*: An identifier meeting the 221 requirements given above in Section 3. 222 o *Description*: A relatively short description of the extension. 223 o *Reference*: Reference to the specification of the extension. 224 o Notes: [optional] 226 The expert(s) can define additional fields to be collected in the 227 registry. 229 Registrations MUST reference a freely available, stable 230 specification, e.g., as described in Section 7 of [RFC2026]. 232 Note that WebAuthn extensions can be registered by third parties 233 (including the expert(s) themselves), if the expert(s) determine that 234 an unregistered extension is widely deployed and not likely to be 235 registered in a timely manner otherwise. Such registrations still 236 are subject to the requirements defined, including the need to 237 reference a specification. 239 3.2. Registration Request Processing 241 As noted in Section 3.1, WebAuthn extension identifiers are 242 registered using the Specification Required policy, implying review 243 and approval by a designated expert. 245 The expert(s) will clearly identify any issues which cause a 246 registration to be refused. 248 When a request is approved, the expert(s) will inform IANA, and the 249 registration will be processed. The IESG is the final arbiter of any 250 objection. 252 3.3. Initial WebAuthn Extension Identifier Registry Values 254 The initial values for the WebAuthn Extension Identifier Registry are 255 to be populated from the values listed in "WebAuthn Extension 256 Identifier Registrations" [10] of [WebAuthn]. 258 4. IANA Considerations 260 4.1. WebAuthn Attestation Statement Format Identifier and Extension 261 Identifiers Registries 263 This specification establishes two registries: 265 o the "WebAuthn Attestation Statement Format Identifier" registry; 266 see Section 2. 267 o the "WebAuthn Extension Identifier" registry; see Section 3. 269 For both registries, the expert(s) and IANA will interact as outlined 270 below: 272 IANA will direct any incoming requests regarding either of these 273 registries to this document and, if defined, the processes 274 established by the expert(s); typically, this will mean referring 275 them to the registry Web page. 277 Note that the expert(s) are allowed (as per Section 2.1) to define 278 additional fields to be collected in the registry. 280 5. Security Considerations 282 See [WebAuthn] for relevant security considerations. 284 6. Acknowledgements 286 Thanks to Mark Nottingham for valuable comments and suggestions. 287 Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area 288 Director sponsorship of this specification. 290 7. Document History 292 [[ to be removed by the RFC Editor before publication as an RFC ]] 294 -03 296 o Update per Benjamin Kaduk's AD review. Align with RFC 8288, 297 rather than draft-nottingham-rfc5988bis. 299 -02 301 o Refresh now that the WebAuthn spec is at Recommendation (REC) 302 maturity level. 304 -01 306 o Refresh now that the WebAuthn Committee Recommendation (CR) draft 307 is pending. 309 -00 311 o Initial version, based on draft-nottingham-rfc5988bis. 313 8. References 315 8.1. Normative References 317 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 318 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 319 . 321 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 322 Specifications: ABNF", STD 68, RFC 5234, 323 DOI 10.17487/RFC5234, January 2008, 324 . 326 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 327 Writing an IANA Considerations Section in RFCs", BCP 26, 328 RFC 8126, DOI 10.17487/RFC8126, June 2017, 329 . 331 [WebAuthn] 332 Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 333 M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 334 "Web Authentication: An API for accessing Public Key 335 Credentials", World Wide Web Consortium 336 (W3C) Recommendation, March 2019, 337 . 339 8.2. URIs 341 [1] https://github.com/w3c/webauthn/ 342 issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries 344 [2] https://tools.ietf.org/html/draft-hodges-webauthn-registries 346 [3] https://github.com/w3c/webauthn/blob/master/draft-hodges- 347 webauthn-registries.txt 349 [4] https://github.com/w3c/webauthn/ 350 pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries 352 [5] https://www.w3.org/TR/webauthn/#sctn-attstn-fmt-ids 354 [6] https://www.iana.org/assignments/(fill-in-here-per-IANA)/ 356 [7] https://www.w3.org/TR/webauthn/#sctn-att-fmt-reg 358 [8] https://www.w3.org/TR/webauthn/#sctn-extension-id 360 [9] https://www.iana.org/assignments/(fill-in-here-per-IANA)/ 362 [10] https://www.w3.org/TR/webauthn/#sctn-extensions-reg 364 Authors' Addresses 366 Jeff Hodges 367 Google 368 1600 Amphitheater Parkway 369 Mountain View, California 94043 370 US 372 Email: jdhodges@google.com 373 URI: http://kingsmountain.com/people/Jeff.Hodges/ 374 Giridhar Mandyam 375 Qualcomm Technologies Inc. 376 5775 Morehouse Drive 377 San Diego, California 92121 378 USA 380 Phone: +1 858 651 7200 381 Email: mandyam@qti.qualcomm.com 383 Michael B. Jones 384 Microsoft 386 Email: mbj@microsoft.com 387 URI: http://self-issued.info/