idnits 2.17.1 draft-wang-eppext-domain-verification-01.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 23 characters in excess of 72. ** The abstract seems to contain references ([RFC5731]), 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 23, 2015) is 3040 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-gould-eppext-verificationcode-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Wang 3 Internet-Draft ZDNS Ltd. 4 Intended status: Informational L. Zhou 5 Expires: June 25, 2016 CNNIC 6 D. Ma 7 ZDNS Ltd. 8 N. Kong 9 X. Lee 10 CNNIC 11 J. Galvin 12 Affilias 13 December 23, 2015 15 Verification Extension for the Extensible Provisioning Protocol (EPP) 16 Domain Name Mapping 17 draft-wang-eppext-domain-verification-01 19 Abstract 21 This mapping describes an verification extension to EPP domain name 22 mapping [RFC5731]. Specified in Extensible Markup Language (XML), 23 this extended mapping is applied to provide additional features 24 required for the provisioning of domain verification. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 25, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 74 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Distinction Type Values . . . . . . . . . . . . . . . . . 4 76 3.2. Verification Status Values . . . . . . . . . . . . . . . 4 77 3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 4 78 3.4. Client Identifier . . . . . . . . . . . . . . . . . . . . 5 79 4. Verification State Diagram . . . . . . . . . . . . . . . . . 5 80 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 82 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 83 5.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 84 5.1.3. EPP Command . . . . . . . . . . . . . . . 10 85 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 86 5.2.1. EPP Command . . . . . . . . . . . . . . . . 10 87 5.2.2. EPP Command . . . . . . . . . . . . . . . . 11 88 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 89 5.2.4. EPP Command . . . . . . . . . . . . . . . 11 90 5.2.5. EPP Command . . . . . . . . . . . . . . . . 11 91 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 92 7. Internationalization Considerations . . . . . . . . . . . . . 13 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 95 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 98 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 99 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 The verification of domain name and registrant identity are required 105 in some registries according to local laws and regulations. The 106 registry should ensure the domain registered does not contain any 107 illegal words and the registrants should pass the real-name 108 verification. There are efforts on verification mechanism by 109 introducing a third party that providing verification service 110 [I-D.draft-gould-eppext-verificationcode]. This method is intended 111 to offer a verification framework but not detail the verification 112 statuses which are employ in practice to indicate the verification 113 process. To be in alignment with the verification status indication 114 mechanism, EPP should be extended accordingly. 116 This document describes an extension mapping for version 1.0 of the 117 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 118 extension to EPP object mappings like the EPP domain name mapping 119 [RFC5731], can be used to retrieve verification information in query 120 commands. 122 This document is specified using the XML 1.0 as described in 123 [W3C.REC-xml-20040204] and XML Schema notation as described in 124 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. 126 2. Conventions Used in This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 In examples, "C:" represents lines sent by a protocol client and "S:" 133 represents lines returned by a protocol server. Indentation and 134 white space in examples are provided only to illustrate element 135 relationships and are not a REQUIRED feature of this specification. 137 XML is case sensitive. Unless stated otherwise, XML specifications 138 and examples provided in this document MUST be interpreted in the 139 character case presented to develop a conforming implementation. 141 veridomain-1.0 in this document is used as an abbreviation for 142 urn:ietf:params:xml:ns:veridomain-1.0. 144 3. Object Attributes 146 This extension adds additional elements to the EPP domain name 147 mapping [RFC5731]. Only the new elements are described here. 149 3.1. Distinction Type Values 151 A domain may be reserved for a particular entity or be prohibited to 152 be registered. Distinction type value descriptions: 154 o reserved. The value "reserved" indicates that a domain name is 155 available but it is reserved for a specific entity, which is only 156 allowed to be used for a element with the attribute 157 "avail" that equals true. 159 o prohibited. The value "prohibited" indicates that a domain name 160 is not allowed to exist in the namespace under a specific Top 161 Level Domain, which is only allowed to be used for a 162 element with the attribute "avail" that equals false. 164 3.2. Verification Status Values 166 The domain object MUST always have one associated verification status 167 value. The verification status value can be set only by the server. 168 The verification status of an object MAY change as a result of an 169 action performed by a server operator. Verification status value 170 descriptions: 172 o unverified. No verification materials are received. 174 o pendingVerify. Verification action has not been completed by the 175 server after receiving verification materials. Server operators 176 can delay action completion for a variety of reasons, such as to 177 allow for human review or third-party action. 179 o pass. Successful verification. 181 o failed. Failed verification. Further verification materials may 182 be needed. 184 3.3. Dates and Times 186 Date and time attribute values MUST be represented in Universal 187 Coordinated Time (UTC) using the Gregorian calendar. The extended 188 date-time form using upper case "T" and "Z" characters defined in 189 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 190 values, as XML Schema does not support truncated date-time forms or 191 lower case "T" and "Z" characters. 193 3.4. Client Identifier 195 The client identifier represents the unique identifier assigned to 196 the client by the server. 198 4. Verification State Diagram 200 Following is a general verification state transition process: 202 1. The initial verification status of a contact is "unverified". 204 2. The registrant submits the proof materials to the registry. 206 3. After receiving the proof materials, the verification status of 207 the contact is changed to "pendingVerify". 209 4. The proof materials pass the human review or third-party 210 verification. 212 5. The verification status is changed to "pass". 214 6. The proof materials are not approved. 216 7. The verification status is changed to "failed". 218 8. If the registrant resubmits the proof materials, the status will 219 be set to "pendingVerify" again. 221 Figure 1: Verification State Diagram 223 | 224 v (2) (4) 225 +----------------+ Material +-----------------+ Approved +----------------+ 226 |unverified (1)| submitted |pendingVerify (3)| |pass (5)| 227 | |---------->| |--------->| | 228 +----------------+ +-----------------+ +----------------+ 229 ^ | 230 | | (6) 231 | | Unapproved +----------------+ 232 | | |failed (7)| 233 | +-------------->| | 234 | +----------------+ 235 | (8) Resubmit | 236 +--------------------------------+ 238 5. EPP Command Mapping 240 A detailed description of the EPP syntax and semantics can be found 241 in the EPP core protocol specification [RFC5730]. The command 242 mappings described here are specifically for use in provisioning and 243 managing verification information via EPP. 245 5.1. EPP Query Commands 247 EPP provides three commands to retrieve domain information: 248 to determine if a domain object can be provisioned within a 249 repository, to retrieve detailed information associated with a 250 domain object, and to retrieve domain-object transfer 251 status information. 253 5.1.1. EPP Command 255 This extension does not add any elements to the EPP command 256 described in the EPP domain name mapping [RFC5731]. However, 257 additional elements are defined for the response. 259 Example command: 261 C: 262 C: 263 C: 264 C: 265 C: 267 C: example.com 268 C: example.net 269 C: 270 C: 271 C: ABC-12345 272 C: 273 C: 275 When an command has been processed successfully, the EPP 276 element MUST contain child elements as described in the EPP 277 domain mapping [RFC5731]. In addition, the EPP element 278 SHOULD contain a child element that identifies 279 the extension namespace if the domain object has data associated with 280 this extension and based on its service policy. The 281 element contains the following child elements: 283 o An OPTIONAL element is designed to 284 indicate whether a domain is allowed to be registered with respect 285 to the verification rules of a specific registry. The element 286 contains the following attributes: 288 * A "name" attribute associates with a specific domain name 289 checked. 291 * A "type" attribute specifies whether a domain is reserved or 292 prohibited as described in section 3.1. 294 Example response: 296 S: 297 S: 298 S: 299 S: 300 S: Command completed successfully 301 S: 302 S: 303 S: 305 S: 306 S: example.com 307 S: 308 S: 309 S: example.net 310 S: 311 S: 312 S: 313 S: 314 S: 315 S: 316 S: 317 S: 318 S: 319 S: 320 S: ABC-12345 321 S: 54322-XYZ 322 S: 323 S: 324 S: 325 5.1.2. EPP Command 327 This extension does not add any element to the EPP command 328 described in the EPP domain mapping [RFC5731]. However, additional 329 elements are defined for the response. 331 Example command: 333 C: 334 C: 335 C: 336 C: 337 C: 338 C: example.com 339 C: 340 C: fooBAR 341 C: 342 C: 343 C: 344 C: ngcl-mIFICBNP 345 C: 346 C: 348 When an command has been processed successfully, the EPP 349 element MUST contain child elements as described in the EPP 350 domain mapping [RFC5731]. In addition, the EPP element 351 SHOULD contain a child element that identifies 352 the extension namespace if the domain object has data associated with 353 this extension and based on its service policy. The 354 element contains the following child elements: 356 o A element that contains the current 357 verification status defined in section 3.2. 359 o An OPTIONAL element contains the 361 o An OPTIONAL element that contains records 362 with history verification process information. The 363 element MUST contain following elements: 365 * element contains a single history record 366 for the verification process. The element 367 MUST contain following elements: 369 + A element contains the date and time when 370 the operation has been executed. 372 + A element contains the name of an operation 373 that has been executed. 375 + A element contains the identifier of an 376 sponsoring client. 378 Example response for an authorized client: 380 S: 381 S: 382 S: 383 S: 384 S: Command completed successfully 385 S: 386 S: 387 S: 388 S: example.com 389 S: EXAMPLE1-REP 390 S: 391 S: jd1234 392 S: sh8013 393 S: sh8013 394 S: sh8013 395 S: 396 S: ns1.example.com 397 S: 398 S: ClientX 399 S: ClientY 400 S: 2015-02-06T04:01:21.0Z 401 S: 2018-02-06T04:01:21.0Z 402 S: 403 S: 2fooBAR 404 S: 405 S: 406 S: 407 S: 408 S: 409 S: pass 410 S: 411 S: 412 S: 2015-2-6T12:00:00.0Z 413 S: PASS 414 S: ClientX 415 S: 416 S: 417 S: 2001-2-3T15:00:00.0Z 418 S: PENDINGVERIFY 419 S: ClientX 420 S: 421 S: 422 S: 2015-2-3T12:00:00.0Z 423 S: UNVERIFIED 424 S: ClientX 425 S: 426 S: 427 S: 428 S: 429 S: 430 S: ngcl-IvJjzMZc 431 S: test142AWQONJZ 432 S: 433 S: 434 S: 436 response for the unauthorized client has not been changed, see 437 [RFC5731] for detail. 439 An EPP error response MUST be returned if an command cannot be 440 processed for any reason. 442 5.1.3. EPP Command 444 This extension does not add any elements to the EPP 445 command or response described in the EPP domain name 446 mapping [RFC5731]. 448 5.2. EPP Transform Commands 450 EPP provides five commands to transform domain objects: to 451 create an instance of a domain object, to delete an instance 452 of a domain object, to extend the validity period of a domain 453 object, to manage domain object sponsorship changes, and 454 to change information associated with a domain object. 456 5.2.1. EPP Command 458 This extension does not add any elements to the EPP command 459 or response described in the EPP domain name mapping 460 [RFC5731] 462 5.2.2. EPP Command 464 This extension does not add any elements to the EPP command 465 or response described in the EPP domain mapping [RFC5731]. 467 5.2.3. EPP Command 469 This extension does not add any elements to the EPP command 470 or response described in the EPP domain mapping [RFC5731]. 472 5.2.4. EPP Command 474 This extension does not add any elements to the EPP 475 command or response described in the EPP domain mapping 476 [RFC5731]. 478 5.2.5. EPP Command 480 This extension does not add any elements to the EPP command 481 or response described in the EPP domain mapping [RFC5731]. 483 6. Formal Syntax 485 An EPP object mapping is specified in XML Schema notation. The 486 formal syntax presented here is a complete schema representation of 487 the object mapping suitable for automated validation of EPP XML 488 instances. The BEGIN and END tags are not part of the schema; they 489 are used to note the beginning and ending of the schema for URI 490 registration purposes. 492 BEGIN 493 495 502 504 506 509 510 511 Extensible Provisioning Protocol v1.0 512 Domain Verification Extension Schema v1.0 513 514 516 517 518 520 521 522 523 524 525 527 528 529 530 531 532 533 534 536 537 538 539 540 541 543 545 546 547 548 549 550 551 552 554 555 556 557 558 559 560 561 563 564 565 566 567 569 570 571 572 573 574 575 577 578 579 END 581 7. Internationalization Considerations 583 EPP is represented in XML, which provides native support for encoding 584 information using the Unicode character set and its more compact 585 representations including UTF-8. Conformant XML processors recognize 586 both UTF-8 and UTF-16. Though XML includes provisions to identify 587 and use other character encodings through use of an "encoding" 588 attribute in an declaration, use of UTF-8 is RECOMMENDED. 590 As an extension of the EPP domain name mapping, the elements, element 591 content described in this document MUST inherit the 592 internationalization conventions used to represent higher-layer 593 domain and core protocol structures present in an XML instance that 594 includes this extension. 596 8. IANA Considerations 598 8.1. XML Namespace 600 This document uses URNs to describe XML namespaces and XML schemas 601 conforming to a registry mechanism described in [RFC3688]. IANA is 602 requested to assignment the following URI. 604 Registration request for the domain verification namespace: 606 o URI: urn:ietf:params:xml:ns:veridomain-1.0 608 o Registrant Contact: See the "Author's Address" section of this 609 document. 611 o XML: See the "Formal Syntax" section of this document. 613 8.2. EPP Extension Registry 615 The EPP extension described in this document should be registered by 616 the IANA in the EPP Extension Registry described in [RFC7451]. The 617 details of the registration are as follows: 619 Name of Extension: Domain Verification Extension 621 Document status: Informational 623 Reference: (insert reference to RFC version of this document) 625 Registrant Name and Email Address: See the "Author's Address" section 626 of this document. 628 TLDs: any 630 IPR Disclosure: none 632 Status: active 634 Notes: none 636 9. Security Considerations 638 The object mapping extension described in this document does not 639 provide any other security services or introduce any additional 640 considerations beyond those described by [RFC5730], [RFC5731] or 641 those caused by the protocol layers used by EPP. 643 10. Acknowledgement 645 The authors would like to thank Galvin Brown from CentralNic for the 646 idea behind use of verification state diagram, and Lin Dong from .top 647 registry for his careful reviews. 649 11. Normative References 651 [I-D.draft-gould-eppext-verificationcode] 652 Gould, J., "Verification Code Extension for the Extensible 653 Provisioning Protocol (EPP)", November 2015, 654 . 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 663 DOI 10.17487/RFC3688, January 2004, 664 . 666 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 667 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 668 . 670 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 671 Domain Name Mapping", STD 69, RFC 5731, 672 DOI 10.17487/RFC5731, August 2009, 673 . 675 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 676 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 677 February 2015, . 679 [W3C.REC-xml-20040204] 680 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 681 F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third 682 Edition)", World Wide Web Consortium FirstEdition REC-xml- 683 20040204", February 2004, 684 . 686 [W3C.REC-xmlschema-1-20041028] 687 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 688 ""XML Schema Part 1: Structures Second Edition", World 689 Wide Web Consortium Recommendation REC-xmlschema- 690 1-20041028", October 2004, 691 . 693 [W3C.REC-xmlschema-2-20041028] 694 Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes 695 Second Edition", World Wide Web Consortium Recommendation 696 REC-xmlschema-2-20041028", October 2004, 697 . 699 Authors' Addresses 701 Wei Wang 702 ZDNS Ltd. 703 4 South 4th Street, Zhongguancun, Haidian District 704 Beijing, Beijing 100190 705 China 707 Email: wangwei@zdns.cn 709 Linlin Zhou 710 CNNIC 711 4 South 4th Street, Zhongguancun, Haidian District 712 Beijing, Beijing 100190 713 China 715 Phone: +86 10 5881 2677 716 Email: zhoulinlin@cnnic.cn 718 Di Ma 719 ZDNS Ltd. 720 4 South 4th Street, Zhongguancun, Haidian District 721 Beijing, Beijing 100190 722 China 724 Email: madi@zdns.cn 726 Ning Kong 727 CNNIC 728 4 South 4th Street, Zhongguancun, Haidian District 729 Beijing, Beijing 100190 730 China 732 Phone: +86 10 5881 3147 733 Email: nkong@cnnic.cn 734 Xiaodong Lee 735 CNNIC 736 4 South 4th Street, Zhongguancun, Haidian District 737 Beijing, Beijing 100190 738 China 740 Phone: +86 10 5881 3020 741 Email: xl@cnnic.cn 743 James Galvin 744 Affilias 745 Afilias USA, Inc. Building 3, Suite 105 300 Welsh Road 746 Horsham, PA 19044 747 US 749 Email: jgalvin@afilias.info