idnits 2.17.1 draft-ietf-regext-allocation-token-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2018) is 2076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track K. Feher 5 Expires: February 22, 2019 Neustar 6 August 21, 2018 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-10 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension for including an Allocation Token in "query" and 16 "transform" commands. The Allocation Token is used as a credential 17 that authorizes a client to request the allocation of a specific 18 object from the server, using one of the EPP transform commands 19 including create and transfer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 22, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 4 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 9 63 3.1.3. EPP Query Command . . . . . . . . . . . . 11 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 12 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 12 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 13 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 13 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 14 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.1. Allocation Token Extension Schema . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 77 6.2. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 17 78 6.3. Neustar gTLD SRS . . . . . . . . . . . . . . . . . . . . 18 79 6.4. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 9.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 86 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 87 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 88 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 21 89 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 21 90 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 21 91 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 21 92 A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 93 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 94 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 21 95 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 21 96 A.11. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 22 97 A.12. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 23 98 A.13. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 23 99 A.14. Change from REGEXT 08 to REGEXT 09 . . . . . . . . . . . 24 100 A.15. Change from REGEXT 09 to REGEXT 10 . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 This document describes an extension mapping for version 1.0 of the 106 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 107 extension to EPP object mappings like the EPP domain name mapping 108 [RFC5731], supports passing an Allocation Token as a credential that 109 authorizes a client to request the allocation of a specific object 110 from the server, using one of the EPP transform commands including 111 create and transfer. 113 Allocation is when a server assigns the sponsoring client of an 114 object based on the use of an Allocation Token credential. Examples 115 include allocating a registration based on a pre-eligibility 116 Allocation Token, allocating a premium domain name registration based 117 on an auction Allocation Token, allocating a registration based on a 118 founders Allocation Token, and allocating an existing domain name 119 held by the server or by a different sponsoring client based on an 120 Allocation Token passed with a transfer command. 122 Clients pass an Allocation Token to the server for validation, and 123 the server determines if the supplied Allocation Token is one 124 supported by the server. It is up to server policy which EPP 125 transform commands and which objects require the Allocation Token. 126 The Allocation Token MAY be returned to an authorized client for 127 passing out-of-band to a client that uses it with an EPP transform 128 command. 130 1.1. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 XML is case sensitive. Unless stated otherwise, XML specifications 139 and examples provided in this document MUST be interpreted in the 140 character case presented in order to develop a conforming 141 implementation. 143 In examples, "C:" represents lines sent by a protocol client and "S:" 144 represents lines returned by a protocol server. Indentation and 145 white space in the examples are provided only to illustrate element 146 relationships and are not REQUIRED in the protocol. 148 The XML namespace prefix "allocationToken" is used for the namespace 149 "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations 150 MUST NOT depend on it and instead employ a proper namespace-aware XML 151 parser and serializer to interpret and output the XML documents. 153 The "abc123" token value is used as a placeholder value in the 154 examples. The server MUST support token values that follow the 155 Security Considerations (Section 7) section. 157 The domain object attribute values, including the "2fooBAR" 158 value, in the examples are provided for illustration 159 purposes only. Refer to [RFC5731] for details on the domain object 160 attributes. 162 2. Object Attributes 164 This extension adds additional elements to EPP object mappings like 165 the EPP domain name mapping [RFC5731]. Only those new elements are 166 described here. 168 2.1. Allocation Token 170 The Allocation Token is a simple XML "token" type. The exact format 171 of the Allocation Token is up to server policy. The server MAY have 172 the Allocation Token for each object to match against the Allocation 173 Token passed by the client to authorize the allocation of the object. 174 The element is used for all of the 175 supported EPP commands as well as the info response. If the supplied 176 Allocation Token passed to the server does not apply to the object, 177 the server MUST return an EPP error result code of 2201. 179 Authorization information, like what is defined in the EPP domain 180 name mapping [RFC5731], is associated with objects to facilitate 181 transfer operations. The authorization information is assigned when 182 an object is created. The Allocation Token and the authorization 183 information are both credentials, but used for different purposes and 184 used in different ways. The Allocation Token is used to facilitate 185 the allocation of an object instead of transferring the sponsorship 186 of the object. The Allocation Token is not managed by the client, 187 but is validated by the server to authorize assigning the initial 188 sponsoring client of the object. 190 An example element with value of 191 "abc123": 193 195 abc123 196 198 3. EPP Command Mapping 200 A detailed description of the EPP syntax and semantics can be found 201 in the EPP core protocol specification [RFC5730]. 203 3.1. EPP Query Commands 205 EPP provides three commands to retrieve object information: 206 to determine if an object can be provisioned, to retrieve 207 information associated with an object, and to retrieve 208 object transfer status information. 210 3.1.1. EPP Command 212 This extension defines additional elements to extend the EPP 213 command of an object mapping like [RFC5731]. 215 This extension allows clients to check the availability of an object 216 with an Allocation Token, as described in Section 2.1. Clients can 217 check if an object can be created using the Allocation Token. The 218 Allocation Token is applied to all object names included in the EPP 219 command. 221 Example command for the allocation.example domain name using 222 the extension with the allocation 223 token of 'abc123': 225 C: 226 C: 227 C: 228 C: 229 C: 231 C: allocation.example 232 C: 233 C: 234 C: 235 C: 238 C: abc123 239 C: 240 C: 241 C: ABC-12345 242 C: 243 C: 245 If the query was successful, the server replies with a 246 response providing the availability status of the queried object 247 based on the following Allocation Token cases, where the object is 248 otherwise available: 250 1. If an object requires an Allocation Token and the Allocation 251 Token does apply to the object, then the server MUST return the 252 availability status as available (e.g., "avail" attribute is "1" 253 or "true"). 254 2. If an object requires an Allocation Token and the Allocation 255 Token does not apply to the object or an object does not require 256 an Allocation Token, then the server SHOULD return the 257 availability status as unavailable (e.g., "avail" attribute is 258 "0" or "false"). 259 3. If an object does not require an Allocation Token, the server MAY 260 return the availability status as available (e.g., "avail" 261 attribute is "1" or "true"). 263 Example domain response for a command using the 264 extension: 266 S: 267 S: 268 S: 269 S: 270 S: Command completed successfully 271 S: 272 S: 273 S: 275 S: 276 S: allocation.example 277 S: Allocation Token mismatch 278 S: 279 S: 280 S: 281 S: 282 S: ABC-DEF-12345 283 S: 54321-XYZ 284 S: 285 S: 286 S: 287 Example command with the 288 extension for the allocation.example and allocation2.example domain 289 names. Availability of allocation.example and allocation2.example 290 domain names are based on the Allocation Token 'abc123': 292 C: 293 C: 294 C: 295 C: 296 C: 298 C: allocation.example 299 C: allocation2.example 300 C: 301 C: 302 C: 303 C: 306 C: abc123 307 C: 308 C: 309 C: ABC-DEF-12345 310 C: 311 C: 312 Example domain response for multiple domain names in the 313 command using the 314 extension: 316 S: 317 S: 318 S: 319 S: 320 S: Command completed successfully 321 S: 322 S: 323 S: 325 S: 326 S: allocation.example 327 S: Allocation Token mismatch 328 S: 329 S: 330 S: allocation2.example 331 S: 332 S: 333 S: 334 S: 335 S: ABC-DEF-12345 336 S: 54321-XYZ 337 S: 338 S: 339 S: 341 This extension does not add any elements to the EPP response 342 described in the [RFC5730]. 344 3.1.2. EPP Command 346 This extension defines additional elements to extend the EPP 347 command of an object mapping like [RFC5731]. 349 The EPP command allows a client to request information 350 associated with an existing object. Authorized clients MAY retrieve 351 the Allocation Token (Section 2.1) along with the other object 352 information by supplying the element in the 353 command. Authorized clients MAY retrieve the Allocation Token 354 (Section 2.1) along with the other object information using the 355 element. The element 356 is an empty element that serves as a marker to the server to return 357 the element in the info response. 358 If the client is not authorized to receive the Allocation Token, the 359 server MUST return an EPP error result code of 2201. If the client 360 is authorized to receive the Allocation Token, but there is no 361 Allocation Token associated with the object, the server MUST return 362 an EPP error result code of 2303. The authorization is subject to 363 server policy. 365 Example command with the allocationToken:info extension for 366 the allocation.example domain name: 368 C: 369 C: 370 C: 371 C: 372 C: 376 C: allocation.example 377 C: 378 C: 379 C: 380 C: 383 C: 384 C: ABC-12345 385 C: 386 C: 388 If the query was successful, the server replies with an 389 element along with the regular EPP 390 . The element is 391 described in Section 2.1. 393 Example domain response using the 394 extension: 396 S: 397 S: 398 S: 399 S: 400 S: Command completed successfully 401 S: 402 S: 403 S: 405 S: allocation.example 406 S: EXAMPLE1-REP 407 S: 408 S: jd1234 409 S: sh8013 410 S: sh8013 411 S: ClientX 412 S: ClientY 413 S: 2012-04-03T22:00:00.0Z 414 S: 415 S: 2fooBAR 416 S: 417 S: 418 S: 419 S: 420 S: 423 S: abc123 424 S: 425 S: 426 S: 427 S: ABC-12345 428 S: 54321-XYZ 429 S: 430 S: 431 S: 433 3.1.3. EPP Query Command 435 This extension does not add any elements to the EPP query 436 command or query response described in [RFC5730]. 438 3.2. EPP Transform Commands 440 EPP provides five commands to transform objects: to create 441 an instance of an object, to delete an instance of an 442 object, to extend the validity period of an object, 443 to manage object sponsorship changes, and to 444 change information associated with an object. 446 3.2.1. EPP Command 448 This extension defines additional elements to extend the EPP 449 command of an object mapping like [RFC5731]. 451 The EPP command provides a transform operation that allows a 452 client to create an instance of an object. In addition to the EPP 453 command elements described in an object mapping like [RFC5731], the 454 command MUST contain a child 455 element for the client to be authorized to create and allocate the 456 object. If the Allocation Token does not apply to the object, the 457 server MUST return an EPP error result code of 2201. 459 Example command to create a domain object with an Allocation 460 Token: 462 C: 463 C: 464 C: 465 C: 466 C: 468 C: allocation.example 469 C: jd1234 470 C: sh8013 471 C: sh8013 472 C: 473 C: 2fooBAR 474 C: 475 C: 476 C: 477 C: 478 C: 481 C: abc123 482 C: 483 C: 484 C: ABC-12345 485 C: 486 C: 488 This extension does not add any elements to the EPP response 489 described in the [RFC5730]. 491 3.2.2. EPP Command 493 This extension does not add any elements to the EPP command 494 or response described in the [RFC5730]. 496 3.2.3. EPP Command 498 This extension does not add any elements to the EPP command 499 or response described in the [RFC5730]. 501 3.2.4. EPP Command 503 This extension defines additional elements to extend the EPP 504 request command of an object mapping like [RFC5731]. 506 The EPP request command provides a transform operation 507 that allows a client to request the transfer of an object. In 508 addition to the EPP command elements described in an object mapping 509 like [RFC5731], the command MUST contain a child 510 element for the client to be 511 authorized to transfer and allocate the object. The authorization 512 associated with the Allocation Token is in addition to and does not 513 replace the authorization mechanism defined for the object's 514 request command. If the Allocation Token is invalid or 515 not required for the object, the server MUST return an EPP error 516 result code of 2201. 518 Example request command to allocate the domain object with 519 the Allocation Token: 521 C: 522 C: 523 C: 524 C: 525 C: 527 C: example1.tld 528 C: 1 529 C: 530 C: 2fooBAR 531 C: 532 C: 533 C: 534 C: 535 C: 538 C: abc123 539 C: 540 C: 541 C: ABC-12345 542 C: 543 C: 545 This extension does not add any elements to the EPP 546 response described in the [RFC5730]. 548 3.2.5. EPP Command 550 This extension does not add any elements to the EPP command 551 or response described in the [RFC5730]. 553 4. Formal Syntax 555 One schema is presented here that is the EPP Allocation Token 556 Extension schema. 558 The formal syntax presented here is a complete schema representation 559 of the object mapping suitable for automated validation of EPP XML 560 instances. The BEGIN and END tags are not part of the schema; they 561 are used to note the beginning and ending of the schema for URI 562 registration purposes. 564 4.1. Allocation Token Extension Schema 566 BEGIN 567 568 572 573 574 Extensible Provisioning Protocol v1.0 575 Allocation Token Extension 576 577 579 580 581 582 583 584 585 586 588 590 592 593 594 595 596 598 599 600 END 602 5. IANA Considerations 604 5.1. XML Namespace 606 This document uses URNs to describe XML namespaces and XML schemas 607 conforming to a registry mechanism described in [RFC3688]. 609 Registration request for the allocationToken namespace: 611 URI: urn:ietf:params:xml:ns:allocationToken-1.0 612 Registrant Contact: IESG 613 XML: None. Namespace URIs do not represent an XML specification. 615 Registration request for the allocationToken XML schema: 617 URI: urn:ietf:params:xml:schema:allocationToken-1.0 618 Registrant Contact: IESG 619 XML: See the "Formal Syntax" section of this document. 621 5.2. EPP Extension Registry 623 The following registration of the EPP Extension Registry, described 624 in [RFC7451], is requested: 626 Name of Extension: "Allocation Token Extension for the Extensible 627 Provisioning Protocol (EPP)" 629 Document status: Standards Track 631 Reference: (insert reference to RFC version of this document) 633 Registrant Name and Email Address: IESG, 635 TLDs: Any 637 IPR Disclosure: None 639 Status: Active 641 Notes: None 643 6. Implementation Status 645 Note to RFC Editor: Please remove this section and the reference to 646 RFC 7942 [RFC7942] before publication. 648 This section records the status of known implementations of the 649 protocol defined by this specification at the time of posting of this 650 Internet-Draft, and is based on a proposal described in RFC 7942 651 [RFC7942]. The description of implementations in this section is 652 intended to assist the IETF in its decision processes in progressing 653 drafts to RFCs. Please note that the listing of any individual 654 implementation here does not imply endorsement by the IETF. 655 Furthermore, no effort has been spent to verify the information 656 presented here that was supplied by IETF contributors. This is not 657 intended as, and must not be construed to be, a catalog of available 658 implementations or their features. Readers are advised to note that 659 other implementations may exist. 661 According to RFC 7942 [RFC7942], "this will allow reviewers and 662 working groups to assign due consideration to documents that have the 663 benefit of running code, which may serve as evidence of valuable 664 experimentation and feedback that have made the implemented protocols 665 more mature. It is up to the individual working groups to use this 666 information as they see fit". 668 6.1. Verisign EPP SDK 670 Organization: Verisign Inc. 672 Name: Verisign EPP SDK 674 Description: The Verisign EPP SDK includes both a full client 675 implementation and a full server stub implementation of draft-ietf- 676 regext-allocation-token. 678 Level of maturity: Production 680 Coverage: All aspects of the protocol are implemented. 682 Licensing: GNU Lesser General Public License 684 Contact: jgould@verisign.com 686 URL: https://www.verisign.com/en_US/channel-resources/domain- 687 registry-products/epp-sdks 689 6.2. Neustar EPP SDK 691 Organisation: Neustar Inc. 693 Name: Neustar EPP SDK 695 Description: The Neustar EPP SDK includes a full client 696 implementation of draft-ietf-regext-allocation-token. 698 Level of maturity: Production 700 Coverage: All aspects of the protocol are implemented. 702 Licensing: GNU Lesser General Public License 704 Contact: quoc-anh.np@team.neustar 706 URL: http://registrytoolkit.neustar 708 6.3. Neustar gTLD SRS 710 Organisation: Neustar Inc. 712 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 713 (SRS). 715 Description: The Neustar gTLD SRS implements the server side of 716 draft-ietf-regext-allocation-token for several Top Level Domains. 718 Level of maturity: Production 720 Coverage: All server side aspects of the protocol are implemented. 722 Licensing: Proprietary 724 Contact: quoc-anh.np@team.neustar 726 6.4. Net::DRI 728 Organization: Dot and Co 730 Name: Net::DRI 732 Description: Net::DRI implements the client-side of draft-ietf- 733 regext-allocation-token. 735 Level of maturity: Production 737 Coverage: All client-side aspects of the protocol are implemented. 739 Licensing: GNU Lesser General Public License 741 Contact: netdri@dotandco.com 743 7. Security Considerations 745 The mapping described in this document does not provide any security 746 services beyond those described by EPP [RFC5730] and protocol layers 747 used by EPP. The security considerations described in these other 748 specifications apply to this specification as well. 750 The mapping acts as a conduit for the passing of Allocation Tokens 751 between a client and a server. The definition of the Allocation 752 Token SHOULD be defined outside of this mapping. The following are 753 security considerations in the definition and use of an Allocation 754 Token: 756 1. An Allocation Token should be considered secret information by 757 the client and SHOULD be protected at rest and MUST be protected 758 in transit. 759 2. An Allocation Token should be single use, meaning it should be 760 unique per object and per allocation operation. 761 3. An Allocation Token should have a limited life with some form of 762 expiry in the Allocation Token if generated by a trusted 3rd 763 third party, or with a server-side expiry if generated by the 764 server. 765 4. An Allocation Token should use a strong random value if it is 766 based on an unsigned code. 767 5. An Allocation Token should leverage digital signatures to confirm 768 its authenticity if generated by a trusted 3rd party. 769 6. An Allocation Token that is signed XML should be encoded (e.g., 770 base64 [RFC4648]) to mitigate server validation issues. 772 8. Acknowledgements 774 The authors wish to acknowledge the original concept for this draft 775 and the efforts in the initial versions of this draft by Trung Tran 776 and Sharon Wodjenski. 778 Special suggestions that have been incorporated into this document 779 were provided by Scott Hollenbeck, Benjamin Kaduk, Mirja Kuehlewind, 780 Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, Eric Rescoria, and 781 Adam Roach. 783 9. References 785 9.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, . 792 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 793 DOI 10.17487/RFC3688, January 2004, . 796 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 797 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 798 . 800 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 801 Domain Name Mapping", STD 69, RFC 5731, 802 DOI 10.17487/RFC5731, August 2009, . 805 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 806 Code: The Implementation Status Section", BCP 205, 807 RFC 7942, DOI 10.17487/RFC7942, July 2016, 808 . 810 9.2. Informative References 812 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 813 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 814 . 816 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 817 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 818 February 2015, . 820 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 821 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 822 May 2017, . 824 Appendix A. Change History 826 A.1. Change from 00 to 01 828 1. Amended XML Namespace section of IANA Considerations, added EPP 829 Extension Registry section. 830 2. Moved Change History to the back section as an Appendix. 832 A.2. Change from 01 to 02 834 1. Ping update. 836 A.3. Change from 02 to 03 838 1. Ping update. 840 A.4. Change from 03 to 04 842 1. Updated the authors for the draft. 844 A.5. Change from 04 to REGEXT 00 846 1. Changed to regext working group draft by changing draft-gould- 847 allocation-token to draft-ietf-regext-allocation-token. 849 A.6. Change from REGEXT 00 to REGEXT 01 851 1. Ping update. 853 A.7. Change from REGEXT 01 to REGEXT 02 855 1. Added the Implementation Status section. 857 A.8. Change from REGEXT 02 to REGEXT 03 859 1. Changed Neustar author to Kal Feher. 861 A.9. Change from REGEXT 03 to REGEXT 04 863 1. Added Neustar implementation to the Implementation Status 864 section. 866 A.10. Change from REGEXT 04 to REGEXT 05 868 1. Updates based on feedback from Patrick Mevzek, that include: 870 1. Remove "or code" from the Abstract section. 871 2. Add a missing "to" in "an allocation token TO one of the 872 EPP..." in the Introduction section. 873 3. Reword the "The allocation token is known to the server..." 874 sentence in the Introduction section. 875 4. Modify the "The allocation token MAY be returned to an 876 authorized client for passing out-of-band to a client that 877 uses it with an EPP transform command" to clarify who the two 878 separate clients are. 879 5. Removed an unneeded ":" from the EPP Command and 880 EPP Command sections. 882 A.11. Change from REGEXT 05 to REGEXT 06 884 1. Fix description of Neustar gTLD SRS based on feedback from Rubens 885 Kuhl. 886 2. Updates based on feedback from Alexander Mayrhofer, that include: 888 1. Making all references to Allocation Token to use the upper 889 case form. 890 2. Revise the language of the abstract to include "for 891 including an Allocation Token in query and transform 892 commands. The Allocation Token is used as a credential that 893 authorizes a client to request the allocation of a specific 894 object from the server, using one of the EPP transform 895 commands..." 896 3. Replace the title "EPP Command" with "EPP 897 Query Command" for section 3.1.3. 898 4. Revise the second sentence of the Introduction to "The 899 mapping, ..., supports passing an Allocation Token..." 900 5. Change "support" to "require" in the Introduction sentence 901 "It is up to server policy which EPP transform commands and 902 which objects support the Allocation Token." 903 6. Add the definition of Allocation to the Introduction. 904 7. Removed "transform" from "all of the supported EPP transform 905 commands" in the "Allocation Token" section, since the 906 Allocation Token can be used with the "check" command as 907 well. 908 8. Remove the word "same" from "The same 909 element is used for 910 all..." in the "Allocation Token" section. 911 9. Change the description of the use of the 2201 error in the 912 "Allocation Token" section, the "EPP Command" 913 section, the "EPP Command" section, and the "EPP 914 Command" section. 915 10. Revise " to determine if an object is known to the 916 server..." to " to determine if an object can be 917 provisioned..." and remove "detailed" in the description of 918 the in the "EPP Query Commands" section. 919 11. Add missing description of the expected response 920 behavior. 921 12. Replaced the example reason "Invalid domain-token pair" with 922 "Allocation Token mismatch". 923 13. Replace "information on" with "information associated with" 924 in the "EPP Command" section. 925 14. Removed the "that identifies the extension namespace", the 926 ", defined in...", the Allocation Token links from the error 927 response sentences, and the "object referencing the 928 element" in the "EPP Command" 929 section. 931 15. Added "The authorization is subject to server policy." to 932 the "EPP Command" section. 933 16. Replace "or response>" with "or query 934 response>" in the EPP Query Command" section. 935 17. Replace "create an object" with "create an instance of an 936 object" in the "EPP Command" section. 937 18. Revised the sentence to include "the command MUST contain a 938 child element for the 939 client to be authorized to create and allocate the object" 940 in the "EPP Command" section. 941 19. Removed the reference to section 2.1 and the namespace 942 identification text in the "EPP Command" section. 943 20. Added "The authorization associated with the Allocation 944 Token is in addition to and does not replace the 945 authorization mechanism defined for the object's 946 request command." to the "EPP Command" section. 947 21. Modified the first sentence of the "EPP Extension Registry" 948 section to read "The following registration of the EPP 949 Extension Registry, described in RFC7451, is requested" 950 22. Removed support with using the Allocation Token with an 951 empty extension of update (e.g., release command), based on 952 the confusion and lack of known applicability. 953 3. Updates based on feedback from Scott Hollenbeck, that include: 955 1. Revised XML schema to included a minimum length of 1 for the 956 allocationTokenType. 957 2. Revised the "IANA Considerations" section to include the 958 registration of the XML schema. 959 3. Revised the "Security Considerations" section to include 960 considerations for the definition of the Allocation Tokens. 962 A.12. Change from REGEXT 06 to REGEXT 07 964 1. Updates based on feedback from Patrick Mevzek: 966 1. Updated obsoleted RFC 7942 to RFC 7942. 967 2. Moved RFC 7451 to an informational reference. 969 A.13. Change from REGEXT 07 to REGEXT 08 971 1. Changed Kal Feher's contact e-mail address. 972 2. Changed Neustar's Implementation Status contact e-mail address. 973 3. Added the Net::DRI sub-section to the Implementation Status 974 section. 976 A.14. Change from REGEXT 08 to REGEXT 09 978 1. Updates based on the AD review by Adam Roach, that include: 980 1. In "Abstract", set "query" and "transform" off in some way 981 (e.g., using quotation marks) 982 2. In "Conventions Used in This Document", please update to use 983 the boilerplate from RFC 8174. 984 3. Remove "allocationToken-1.0" is used as an abbreviation for 985 "urn:ietf:params:xml:ns:allocationToken-1.0". 986 4. In "Allocation Token", change "The server MUST have the 987 Allocation Token" to "The server MAY have the Allocation 988 Token". 989 5. In "EPP Command", change "This extension allow 990 clients" to "This extension allows clients". 991 6. Use domains reserved by RFC 2026 for the examples. The 992 example domain "example.tld" was changed to 993 "allocation.example" and the example domain "example2.tld" 994 was changed to "allocation2.example". 995 7. In "EPP Command", change "...the server MUST return 996 an EPP error result code of 2303 object referencing the 997 element." to "...the server MUST 998 return an EPP error result code of 2303." 999 8. In "EPP Query Command", remove "the" before 1000 "RFC5730". 1001 9. In "EPP Command", change "If the Allocation Token 1002 does not apply to the object..." to "If the Allocation Token 1003 is invalid or not required for the object...". 1004 10. In "XML Namespace", remove the sentence "The following URI 1005 assignment is requested of IANA:" 1006 11. In "Security Considerations", change "An Allocation Token 1007 should is" to "An Allocation Token that is". Also 1008 informatively cite RFC 4648 for the base64 reference. 1009 2. Change "ietf:params:xml:ns:allocationToken-1.0" to 1010 "ietf:params:xml:schema:allocationToken-1.0" for the XML schema 1011 IANA registration. 1013 A.15. Change from REGEXT 09 to REGEXT 10 1015 1. Changed "auhorization" to "authorization" in the "EPP 1016 Command" section. 1017 2. Added 'If an object does not require an Allocation Token, the 1018 server MAY return the availability status as available (e.g., 1019 "avail" attribute is "1" or "true").' to the check response 1020 cases, based on feedback by Mirja Kuehlewind. 1021 3. Changed the definition of the element in the XML schema to 1022 only allow an empty element, based on IANA's expert review. 1024 4. Added normative language to the storage and transport of the 1025 Allocation Token, in the "Security Considerations" section, based 1026 on feedback from Eric Rescoria. 1027 5. Changed "The definition of the Allocation Token is defined 1028 outside of this mapping" to "The definition of the Allocation 1029 Token SHOULD be defined outside of this mapping", in the 1030 "Security Considerations" section, based on feedback from Eric 1031 Rescoria. 1032 6. Added the missing "urn:" prefix with the IANA URI registrations. 1033 7. The URL for the BCP 14 was removed based on feedback from Alissa 1034 Cooper. 1035 8. Updates based on review by Benjamin Kaduk, that include: 1037 1. Added the second paragraph to the "Allocation Token" section 1038 to describe the difference (motivation) of using the 1039 Allocation Token versus the EPP RFC authorization mechanism. 1040 2. Added a paragraph to the "Conventions Used in This Document" 1041 section for the use of the "abc123" token value and the use 1042 of domain object "2fooBAR" password value in the examples. 1043 3. Changed the "A client MUST pass an Allocation Token known to 1044 the server to be authorized to use one of the supported EPP 1045 transform commands." sentence in the "Introduction" section 1046 to "Clients pass an Allocation Token to the server for 1047 validation, and the server determines if the supplied 1048 Allocation Token is one supported by the server." 1049 4. Changed the "Indentation and white space in the examples are 1050 provided only to illustrate element relationships and are not 1051 REQUIRED in the protocol." sentence in the "Conventions Used 1052 in This Document" section to "Indentation and white space in 1053 the examples are provided only to illustrate element 1054 relationships and are not REQUIRED in the protocol." 1055 5. Changed the "Authorized clients MAY retrieve..." sentence in 1056 the "EPP Command" section. 1057 6. Changed the "If the query was successful..." sentence in the 1058 "EPP Command" section. 1059 7. Added "supplied" to the "If the supplied Allocation Token 1060 passed..." sentence in the "Allocation Token" section. 1061 8. Removed an extra newline in the element in the 1062 "Allocation Token Extension Schema" section. 1064 Authors' Addresses 1065 James Gould 1066 VeriSign, Inc. 1067 12061 Bluemont Way 1068 Reston, VA 20190 1069 US 1071 Email: jgould@verisign.com 1072 URI: http://www.verisigninc.com 1074 Kal Feher 1075 Neustar 1076 lvl 8/10 Queens Road 1077 Melbourne, VIC 3004 1078 AU 1080 Email: ietf@feherfamily.org 1081 URI: http://www.neustar.biz