idnits 2.17.1 draft-ietf-regext-verificationcode-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 : ---------------------------------------------------------------------------- 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 (November 21, 2018) is 1976 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 November 21, 2018 5 Expires: May 25, 2019 7 Verification Code Extension for the Extensible Provisioning Protocol 8 (EPP) 9 draft-ietf-regext-verificationcode-05 11 Abstract 13 This document describes an Extensible Provisioning Protocol (EPP) 14 extension for including a verification code for marking the data for 15 a transform command as being verified by a 3rd party, which is 16 referred to as the Verification Service Provider (VSP). The 17 verification code is digitally signed by the VSP using XML Signature 18 and is "base64" encoded. The XML Signature includes the VSP signer 19 certificate, so the server can verify that the verification code 20 originated from the VSP. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 25, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Verification Code . . . . . . . . . . . . . . . . . . . . 4 60 2.1.1. Signed Code . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.2. Encoded Signed Code . . . . . . . . . . . . . . . . . 7 62 2.2. Verification Profile . . . . . . . . . . . . . . . . . . 11 63 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 64 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 12 65 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 12 66 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 12 67 3.1.3. EPP Command . . . . . . . . . . . . . . . 24 68 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 25 69 3.2.1. EPP Command . . . . . . . . . . . . . . . . 25 70 3.2.2. EPP Command . . . . . . . . . . . . . . . . 27 71 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 28 72 3.2.4. EPP Command . . . . . . . . . . . . . . . 28 73 3.2.5. EPP Command . . . . . . . . . . . . . . . . 28 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28 75 4.1. Verification Code Extension Schema . . . . . . . . . . . 28 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 77 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 78 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 79 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 80 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 33 81 6.2. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 34 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 85 8.2. Informative References . . . . . . . . . . . . . . . . . 36 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 87 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 36 88 B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 36 89 B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 36 90 B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 36 91 B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 92 B.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 37 93 B.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 37 94 B.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 37 95 B.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 37 96 B.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 37 97 B.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 37 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 100 1. Introduction 102 This document describes an extension mapping for version 1.0 of the 103 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 104 extension to EPP object mappings like the EPP domain name mapping 105 [RFC5731], EPP host mapping [RFC5732], and EPP contact mapping 106 [RFC5733], can be used to pass a verification code to one of the EPP 107 transform commands. The domain name object is used for examples in 108 the document. The verification code is signed using XML Signature 109 [W3C.CR-xmldsig-core2-20120124] and is "base64" encoded. The 110 "base64" encoded text of the verification code MUST conform to 111 [RFC2045]. The verification code demonstrates that verification was 112 done by a Verification Service Provider (VSP). 114 The Verification Service Provider (VSP) is a certified party to 115 verify that data is in compliance with the policies of a locality. A 116 locality MAY require the client to have data verified in accordance 117 with local regulations or laws utilizing data sources not available 118 to the server. The VSP has access to the local data sources and is 119 authorized to verify the data. Examples include verifying that the 120 domain name is not prohibited and verifying that the domain name 121 registrant is a valid individual, organization, or business in the 122 locality. The data verified, and the objects and operations that 123 require the verification code to be passed to the server, is up to 124 the policies of the locality. The verification code represents a 125 marker that the verification was completed. The VSP MUST store the 126 proof of verification and the generated verification code; and MAY 127 store the verified data. The signer certificate and the digital 128 signature of the verification code MUST be verified by the server. 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 examples are provided only to illustrate element 146 relationships and are not a REQUIRED feature of this protocol. 148 "verificationCode-1.0" is used as an abbreviation for 149 "urn:ietf:params:xml:ns:verificationCode-1.0". The XML namespace 150 prefix "verificationCode" is used, but implementations MUST NOT 151 depend on it and instead employ a proper namespace-aware XML parser 152 and serializer to interpret and output the XML documents. 154 2. Object Attributes 156 This extension adds additional elements to EPP object mappings like 157 the EPP domain name mapping [RFC5731], EPP host mapping [RFC5732], 158 and EPP contact mapping [RFC5733]. Only those new elements are 159 described here. 161 2.1. Verification Code 163 The Verification Code is a formatted token, referred to as the 164 Verification Code Token, that is digitally signed by a Verification 165 Service Provider (VSP) using XML Signature 166 [W3C.CR-xmldsig-core2-20120124], using the process described in 167 Section 2.1.1, and is then "base64" encoded, as defined in 168 Section 2.1.2. The Verification Code Token syntax is specified using 169 Augmented Backus-Naur Form (ABNF) grammar [RFC5234] as follows: 171 Verification Code Token ABNF 173 token = vsp-id "-" verification-id ; Verification Code Token 174 vsp-id = 1*DIGIT ; VSP Identifier 175 verification-id = 1*(DIGIT / ALPHA) ; Verification Identifier 177 For a VSP given VSP Identifier "1" and with a Verification Identifier 178 of "abc123", the resulting Verification Code Token is "1-abc123". 179 The Verification Identifier MUST be unique within a VSP and the VSP 180 Identifier MUST be unique across supporting VSP's, so the 181 Verification Code Token MUST be unique to an individual verification. 182 The VSP Identifiers MAY require registration within an IANA registry. 184 2.1.1. Signed Code 186 The is the fragment of XML that is 187 digitally signed using XML Signature [W3C.CR-xmldsig-core2-20120124]. 188 The element includes a required "id" 189 attribute of type XSD ID for use with an IDREF URI from the Signature 190 element. The certificate of the issuer MUST be included with the 191 Signature so it can be chained with the issuer's certificate by the 192 validating client. 194 The element includes a REQUIRED "type" 195 attribute for use in defining the type of the signed code. It is up 196 to the VSP and the server to define the valid values for the "type" 197 attribute. Examples of possible "type" attribute values include 198 "domain" for verification of the domain name, "registrant" for 199 verification of the registrant contact, or "domain-registrant" for 200 verification of both the domain name and the registrant. The typed 201 signed code is used to indicate the verifications that are done by 202 the VSP. The "type" attribute values MAY require registration within 203 an IANA registry. 205 A element substitutes for the 206 abstract element to define a 207 concrete definition of a signed code. The 208 element can be replaced by 209 other signed code definitions using the XML schema substitution 210 groups feature. 212 The child elements of the element 213 include: 215 Contains the Verification Code Token as 216 defined by the ABNF in Section 2.1. 217 XML Signature [W3C.CR-xmldsig-core2-20120124] for the 218 . Use of a namespace prefix, like 219 "dsig", is recommended for the XML Signature 220 [W3C.CR-xmldsig-core2-20120124] elements. 222 Example of a "domain" typed signed code using the 223 element and XML Signature 224 [W3C.CR-xmldsig-core2-20120124]: 226 230 1-abc111 231 232 233 234 236 238 239 240 242 243 245 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 246 247 248 249 250 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 251 QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD 252 o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+ 253 jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi 254 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z 255 ipJsXNa6osTUw1CzA7jfwA== 256 257 258 259 260 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 261 MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO 262 TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw 263 MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex 264 FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh 265 MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B 266 AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw 267 WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u 268 pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7 269 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5 270 sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v 271 L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG 272 A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV 273 HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV 274 UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ 275 Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P 276 AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn 277 L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/ 278 IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu 279 y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R 280 bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk 281 wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL 282 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 283 284 285 286 287 289 2.1.2. Encoded Signed Code 291 The element contains one or more 292 encoded form of the digitally signed 293 element, described in Section 2.1.1. 295 The child elements of the 296 element include: 298 One or more elements 299 that is an encoded form of the digitally signed 300 element, described in 301 Section 2.1.1, with the encoding defined by the "encoding" 302 attribute with the default "encoding" value of "base64". The 303 "base64" encoded text of the element MUST 304 conform to [RFC2045]. 306 Example element that contains 307 one "base64" encoded contained in the 308 element: 310 313 314 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 315 OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 316 bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 317 b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 318 ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 319 dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 320 PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 321 My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 322 aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 323 Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 324 Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 325 aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 326 ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 327 dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 328 YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 329 UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 330 ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 331 UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 332 Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 333 amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 334 bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 335 CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 336 d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 337 SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 338 VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 339 CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 340 ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 341 d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 342 bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 343 eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 344 d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 345 R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 346 UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 347 c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 348 QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 349 cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 350 NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 351 MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 352 ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 353 WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 354 QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 355 Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 356 Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 357 SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 358 LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 359 VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 360 R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 361 SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 362 Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 363 bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 364 MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 365 REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 366 aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 367 N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 368 aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 369 L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 370 TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 371 UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 372 YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 373 b25Db2RlOnNpZ25lZENvZGU+Cg== 374 375 377 Example element that contains 378 two elements ;. 380 381 382 383 384 386 domain.example 387 jd1234 388 sh8013 389 sh8013 390 391 2fooBAR 392 393 394 395 396 399 400 ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 401 OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 402 bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 403 b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 404 ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 405 dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 406 PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 407 My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 408 aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 409 Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 410 Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 411 aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 412 ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 413 dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 414 YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 415 UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 416 ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 417 UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 418 Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 419 amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 420 bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 421 CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 422 d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 423 SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 424 VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 425 CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 426 ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 427 d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 428 bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 429 eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 430 d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 431 R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 432 UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 433 c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 434 QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 435 cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 436 NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 437 MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 438 ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 439 WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 440 QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 441 Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 442 Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 443 SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 444 LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 445 VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 446 R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 447 SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 448 Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 449 bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 450 MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 451 REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 452 aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 453 N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 454 aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 455 L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 456 TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 457 UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 458 YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 459 b25Db2RlOnNpZ25lZENvZGU+Cg== 460 461 462 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48dmVyaWZpY2F0 463 aW9uQ29kZTpzaWduZWRDb2RlIHhtbG5zOnZlcmlmaWNhdGlvbkNvZGU9InVybjpp 464 ZXRmOnBhcmFtczp4bWw6bnM6dmVyaWZpY2F0aW9uQ29kZS0xLjAiIGlkPSJzaWdu 465 ZWRDb2RlIiB0eXBlPSJyZWdpc3RyYW50Ij48dmVyaWZpY2F0aW9uQ29kZTpjb2Rl 466 PjEtYWJjMjIyPC92ZXJpZmljYXRpb25Db2RlOmNvZGU+PGRzaWc6U2lnbmF0dXJl 467 IHhtbG5zOmRzaWc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMi 468 Pjxkc2lnOlNpZ25lZEluZm8+PGRzaWc6Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBB 469 bGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRu 470 LTIwMDEwMzE1I1dpdGhDb21tZW50cyIvPjxkc2lnOlNpZ25hdHVyZU1ldGhvZCBB 471 bGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Et 472 c2hhMSIvPjxkc2lnOlJlZmVyZW5jZSBVUkk9IiNzaWduZWRDb2RlIj48ZHNpZzpU 473 cmFuc2Zvcm1zPjxkc2lnOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cu 474 dzMub3JnLzIwMDAvMDkveG1sZHNpZyNlbnZlbG9wZWQtc2lnbmF0dXJlIi8+PC9k 475 c2lnOlRyYW5zZm9ybXM+PGRzaWc6RGlnZXN0TWV0aG9kIEFsZ29yaXRobT0iaHR0 476 cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjc2hhMjU2Ii8+PGRzaWc6RGln 477 ZXN0VmFsdWU+SFg2TU1WUWdnSStzNG9tT3haYjBGTW1VSlBRdk15WmUybDVEdEhh 478 QlZMND08L2RzaWc6RGlnZXN0VmFsdWU+PC9kc2lnOlJlZmVyZW5jZT48L2RzaWc6 479 U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx1ZT5VOUhPNVlYVWE0ZUsyYXRz 480 U1RuQk1DU3dXM0dWUzZnUEtkaDBZTlZicERud1d4b1BtYlR2YkVsNDE4NFlKZ3Uw 481 WXB3RkROMmZLY3JVCk1YV0hncE56K0oycTh6MWpTcVJMUEw0UmpnRWw0eGhiOXl5 482 cExOZC8xQXJXRVlhWWZEdUc1S3FYV05MRG5YVzJoQkEzK0R5Wk82MFQKcTVPd0R5 483 ZVFSVlNPVWNXVE9FOTJsSlZ4M014Q1V6d1hoL0ZOSTlPbGtXK0ZPNVZNNTZlTmZq 484 UEhkUlJVdjdzQzRmM0NnWmFaSWFXNQp2RmJnTmJodFJVa0hsSVhnYVNGWDgvcFdV 485 RXFIY0dLTUxnRU1nbHBnQ3RtOFlIcXVqb0tXUk0yUDNiK2h3ZTRsU0hSWVRjK0pB 486 eEluClU4RDc1WnliWThnSWFuZUprS2dwVTk2T0tJTGQ5L0l0UVhaeHZnPT08L2Rz 487 aWc6U2lnbmF0dXJlVmFsdWU+PGRzaWc6S2V5SW5mbz48ZHNpZzpYNTA5RGF0YT48 488 ZHNpZzpYNTA5Q2VydGlmaWNhdGU+TUlJRGlUQ0NBbkdnQXdJQkFnSUVmcXE2SFRB 489 TkJna3Foa2lHOXcwQkFRc0ZBREIxTVJBd0RnWURWUVFHRXdkVmJtdHViM2R1TVJB 490 dwpEZ1lEVlFRSUV3ZFZibXR1YjNkdU1SQXdEZ1lEVlFRSEV3ZFZibXR1YjNkdU1S 491 QXdEZ1lEVlFRS0V3ZFZibXR1YjNkdU1SQXdEZ1lEClZRUUxFd2RWYm10dWIzZHVN 492 Umt3RndZRFZRUURFeEIyWlhKcFptbGpZWFJwYjI1RGIyUmxNQjRYRFRFMU1EWXhO 493 VEl4TURBeU1sb1gKRFRNMU1EWXhNREl4TURBeU1sb3dkVEVRTUE0R0ExVUVCaE1I 494 Vlc1cmJtOTNiakVRTUE0R0ExVUVDQk1IVlc1cmJtOTNiakVRTUE0RwpBMVVFQnhN 495 SFZXNXJibTkzYmpFUU1BNEdBMVVFQ2hNSFZXNXJibTkzYmpFUU1BNEdBMVVFQ3hN 496 SFZXNXJibTkzYmpFWk1CY0dBMVVFCkF4TVFkbVZ5YVdacFkyRjBhVzl1UTI5a1pU 497 Q0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUpjY2pY 498 cmsKUWFJL2lHUEZ3WmVITjFnRFVhcTltVnJmQis2eWR5Qmdoc2FHVFZoaERIOFNO 499 TmtpamxIMkxCQ3J3TjhjVjhQZ1BPOXRwbG9rR2F5UwpxNktFaHZtTk03b1dsZk5L 500 SkdSdGNidGMzTnJuYzhiUUJacU1xcFo0UlNRTmh5QWh6Ri85UmErd3RFc0JWeGF3 501 VDc1L2J0SDZ1YytmClJOdE5FcmhJdVlJUmN0WTZIRmRaR3BlS3cxYnlYK0RsNkJP 502 L3ZLdnQ4NDllY1R3aEZIcDUwWGh2NFVTL0Z5aWVLaGs3dDdHRnJGRlQKL2NCTGsy 503 WmxFa1lLcFlEU2dlc2lseFg2QkpTZVdCbXZLQzlTL2pBZDhNWmRHVUg2aHNHRXBl 504 U1BmZkZQV3FWcXl6V0p5bG91OXF4ZQpnUTZjOFo2SVpXZkUzakxSOUVySDhzOTFD 505 Mm1pTFZrQ0F3RUFBYU1oTUI4d0hRWURWUjBPQkJZRUZIY0JLdk03dmk3dUZNTUx5 506 ZE43CmVGVXF2YzVVTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBVjB2cmlrSWRB 507 d2l4THZ0NUx5eXpTNFdTU1d0dVlWL2JQMVg3NzVMRmYKSWh3a2xoMENidk5rYXlK 508 Tms2Tnp0eDlSc1AwNWZndkxrZER1N0V5cnRzY3I1ZVdETG1WMGtKMWE1N1Z4bnJh 509 aEdLTnM2Wit1Ui9pSApMaTJXb3liWEpFT2N0NWtJSjFzL05CeUUrdkdGdjFoTmJz 510 dVVVUEVCYWVtaWpYUFROOWxxZE9uM1FIbktobXhsa1czYS9KbmhtT20vCkRWYTE0 511 NDJXTVVUSlUyVFlWVldtdUs2NFkwQXFrN2FldzkvVzIzZEcrT2xhOW9VYnBrSXJr 512 dDRDN3hRa0d5SXN2eUo3bi91OFhBRDIKbno1T1cvek5GWnlrZDAzT2N3M240NkZx 513 c1IwVDlBbFBEWHQxUjlmMjZMd1lxdjk3dWtVNEcrMVRJNHorV0F2TCtVRk9FVnNu 514 PC9kc2lnOlg1MDlDZXJ0aWZpY2F0ZT48L2RzaWc6WDUwOURhdGE+PC9kc2lnOktl 515 eUluZm8+PC9kc2lnOlNpZ25hdHVyZT48L3ZlcmlmaWNhdGlvbkNvZGU6c2lnbmVk 516 Q29kZT4= 517 518 519 520 ABC-12345 521 522 524 2.2. Verification Profile 526 A Verification Profile defines the set of verification code types, 527 the commands that the verification code types are required, 528 supported, or not supported, and the grace period by which the 529 verification code types MUST be set. It is up to server policy what 530 action to take if the verification code type is not set by the grace 531 period. A server MAY support many verification profiles, each with a 532 unique name and a unique verification policy that is implemented by 533 the server. Each client MAY have zero or more server assigned 534 verification profiles that will enforce the required verification 535 policies. Most likely a client will be assigned zero or one server 536 assigned verification profile, but overlapping profiles is possible. 537 Overlapping verification profiles MUST be treated as a logical "and" 538 of the policies by the server. If no verification profile is 539 assigned to the client, no additional verification is required by the 540 client. 542 3. EPP Command Mapping 544 A detailed description of the EPP syntax and semantics can be found 545 in the EPP core protocol specification [RFC5730]. 547 3.1. EPP Query Commands 549 EPP provides three commands to retrieve object information: 550 to determine if an object is known to the server, to retrieve 551 detailed information associated with an object, and to 552 retrieve object transfer status information. 554 3.1.1. EPP Command 556 This extension does not add any elements to the EPP command 557 or response described in the [RFC5730]. 559 3.1.2. EPP Command 561 This extension defines additional elements to extend the EPP 562 command of an object mapping like the EPP domain name mapping 563 [RFC5731], EPP host mapping [RFC5732], and EPP contact mapping 564 [RFC5733]. 566 The EPP command is used to retrieve the verification 567 information. The verification information is based on the 568 verification profile, as defined in Section 2.2, set in the server 569 for the client. The element is an empty 570 element that indicates that the client requests the verification 571 information. The OPTIONAL "profile" attribute can be used by the 572 client to explicitly specify a verification profile, as defined in 573 Section 2.2, to base the verification information on. It is up to 574 server policy on the set of verification profiles that the client is 575 allowed to explicitly specify, and if the client is not allowed, the 576 server MUST return the 2201 error response. 578 Example domain command with the 579 extension to retrieve the verification information for the domain 580 "domain.example", using the profiles associated with the client: 582 C: 583 C: 584 C: 585 C: 586 C: 588 C: domain.example 589 C: 590 C: 591 C: 592 C: 595 C: 596 C: ABC-12345 597 C: 598 C: 600 Example domain command with the 601 extension to retrieve the verification information for the domain 602 "domain.example", using the profiles associated with the client and 603 with the authorization information to retrieve the verification codes 604 from the non-sponsoring client: 606 C: 607 C: 608 C: 609 C: 610 C: 612 C: domain.example 613 C: 614 C: 2fooBAR 615 C: 616 C: 617 C: 618 C: 619 C: 622 C: 623 C: ABC-12345 624 C: 625 C: 626 Example domain command with the 627 extension to retrieve the verification information for the domain 628 "domain.example", using the the "sample" profile: 630 C: 631 C: 632 C: 633 C: 634 C: 636 C: domain.example 637 C: 638 C: 639 C: 640 C: 644 C: 645 C: ABC-12345 646 C: 647 C: 649 If the query was successful, the server replies with a 650 element along with the regular EPP 651 . The element contains the 652 following child elements: 654 The status of the verification for the 655 object, using all of the verification profiles assigned to the 656 client. There are four possible values for the status: 658 notApplicable The status is not applicable to the client since 659 there is no assigned verification profile. 660 nonCompliant The object is non-compliant according to the 661 verification profiles. If at least one of the profiles is 662 "nonCompliant", the object is "nonCompliant". 663 pendingCompliance The object is not in compliance with the 664 verification profiles, but has a grace period to set the 665 required set of verification codes, as reflected by the due 666 date of the verification code type. If at least one of the 667 profiles is "pendingCompliance" and none of the profiles is 668 "nonCompliant", the object is "pendingCompliance". 669 compliant The object is compliant with the verification 670 profiles. If All of the profiles for the object are 671 "compliant" or if the object has no assignd profiles, the 672 object is "compliant". 674 Zero or more OPTIONAL 675 elements that defines the verification 676 status of the object based on the profile. The required "name" 677 attribute defines the name of the profile. The 678 element contains the following child 679 elements: 681 The status of the verification for the 682 object and the profile. There are four possible values for 683 the status: 685 notApplicable The profile status is not applicable to the 686 client based on the assigned verification profiles or the 687 profile specified. 688 nonCompliant The object is non-compliant according to the 689 verification profile. 690 pendingCompliance The object is not in compliance with the 691 verification profile, but has a grace period to set the 692 required set of verification codes, as reflected by the 693 due date of the verification code type. 694 compliant The object is compliant with the verification 695 profile. 696 OPTIONAL list of missing verification 697 code types. The element is 698 returned only if there is at least one missing verification 699 code type and based on server policy. The 700 element contains the following 701 child elements: 703 One or more 704 elements that is empty with the REQUIRED "type" attribute 705 that indicates the verification code type and the 706 REQUIRED "due" attribute that indicates when the 707 verification code type was or is due. Past due 708 verification code types will result in the 709 element being set to 710 "nonCompliant". 711 OPTIONAL list of set verification codes. 712 The element is returned only if there 713 is at least one set verification code. The 714 element contains the following child 715 elements: 717 One or more 718 elements containing the verification code with a REQUIRED 719 "type" attribute that indicates the code type and a 720 REQUIRED "date" attribute that indicates when the 721 verification code was set. The inclusion of the code 722 value is up server policy, so if the server determines 723 that the code value cannot be exposed to a non-sponsoring 724 client, the element MUST be 725 empty. 727 Example domain response using the 728 extension for a compliant domain using the "sample" profile, and with 729 the two verification codes, from the sponsoring or authorized client: 731 S: 732 S: 733 S: 734 S: 735 S: Command completed successfully 736 S: 737 S: 738 S: 740 S: domain.example 741 S: DOMAIN-REP 742 S: 743 S: ClientX 744 S: ClientY 745 S: 2010-04-03T22:00:00.0Z 746 S: 747 S: 2015-04-03T22:00:00.0Z 748 S: 749 S: 750 S: 2fooBAR 751 S: 752 S: 753 S: 754 S: 755 S: 758 S: compliant 759 S: 760 S: 761 S: compliant 762 S: 763 S: 764 S: 1-abc333 766 S: 767 S: 1-abc444 769 S: 770 S: 771 S: 772 S: 773 S: 774 S: 775 S: ABC-12345 776 S: 54322-XYZ 777 S: 778 S: 779 S: 781 Example domain response using the 782 extension for a compliant domain using the "sample" profile, and with 783 the two verification codes, from the sponsoring or authorized client 784 that also includes codes set for the "sample2" profile: 786 S: 787 S: 788 S: 789 S: 790 S: Command completed successfully 791 S: 792 S: 793 S: 795 S: domain.example 796 S: DOMAIN-REP 797 S: 798 S: ClientX 799 S: ClientY 800 S: 2010-04-03T22:00:00.0Z 801 S: 802 S: 2015-04-03T22:00:00.0Z 803 S: 804 S: 805 S: 2fooBAR 806 S: 807 S: 808 S: 809 S: 810 S: 813 S: compliant 814 S: 815 S: 816 S: compliant 817 S: 818 S: 819 S: 1-abc333 821 S: 822 S: 1-abc444 824 S: 825 S: 826 S: 827 S: 828 S: notApplicable 829 S: 830 S: 831 S: 2-abc555 833 S: 834 S: 835 S: 836 S: 837 S: 838 S: 839 S: ABC-12345 840 S: 54322-XYZ 841 S: 842 S: 843 S: 844 Example domain response using the 845 extension for a compliant domain using the "sample" profile, and with 846 the two verification code types, from the non-sponsoring client: 848 S: 849 S: 850 S: 851 S: 852 S: Command completed successfully 853 S: 854 S: 855 S: 857 S: domain.example 858 S: DOMAIN-REP 859 S: 860 S: ClientX 861 S: ClientY 862 S: 2010-04-03T22:00:00.0Z 863 S: 864 S: 2015-04-03T22:00:00.0Z 865 S: 866 S: 867 S: 868 S: 869 S: 872 S: compliant 873 S: 874 S: 875 S: compliant 876 S: 877 S: 878 S: 880 S: 882 S: 883 S: 884 S: 885 S: 886 S: 887 S: ABC-12345 888 S: 54322-XYZ 889 S: 890 S: 891 S: 892 Example domain response using the 893 extension for a non-compliant domain using the "sample" profile, and 894 with the verification code types missing along with their due dates: 896 S: 897 S: 898 S: 899 S: 900 S: Command completed successfully 901 S: 902 S: 903 S: 905 S: domain.example 906 S: DOMAIN-REP 907 S: 908 S: ClientX 909 S: ClientY 910 S: 2010-04-03T22:00:00.0Z 911 S: 912 S: 2015-04-03T22:00:00.0Z 913 S: 914 S: 915 S: 916 S: 917 S: 920 S: nonCompliant 921 S: 922 S: 923 S: nonCompliant 924 S: 925 S: 926 S: 929 S: 932 S: 933 S: 934 S: 935 S: 936 S: 937 S: ABC-12345 938 S: 54322-XYZ 939 S: 940 S: 941 S: 943 Example domain response using the 944 extension for a pending compliance domain using the "sample" profile, 945 with the verification code type missing along with the due date, and 946 with set verification code: 948 S: 949 S: 950 S: 951 S: 952 S: Command completed successfully 953 S: 954 S: 955 S: 957 S: domain.example 958 S: DOMAIN-REP 959 S: 960 S: ClientX 961 S: ClientY 962 S: 2010-04-03T22:00:00.0Z 963 S: 964 S: 2015-04-03T22:00:00.0Z 965 S: 966 S: 967 S: 968 S: 969 S: 972 S: pendingCompliance 973 S: 974 S: 975 S: pendingCompliance 976 S: 977 S: 978 S: 981 S: 982 S: 983 S: 1-abc333 985 S: 986 S: 987 S: 988 S: 989 S: 990 S: 991 S: ABC-12345 992 S: 54322-XYZ 993 S: 994 S: 995 S: 996 Example domain response using the 997 extension for a client that does not have a verification profile 998 assigned: 1000 S: 1001 S: 1002 S: 1003 S: 1004 S: Command completed successfully 1005 S: 1006 S: 1007 S: 1009 S: domain.example 1010 S: DOMAIN-REP 1011 S: 1012 S: ClientX 1013 S: ClientY 1014 S: 2010-04-03T22:00:00.0Z 1015 S: 1016 S: 2015-04-03T22:00:00.0Z 1017 S: 1018 S: 1019 S: 1020 S: 1021 S: 1024 S: notApplicable 1025 S: 1026 S: 1027 S: 1028 S: 1029 S: ABC-12345 1030 S: 54322-XYZ 1031 S: 1032 S: 1033 S: 1035 3.1.3. EPP Command 1037 This extension does not add any elements to the EPP query 1038 command or response described in the [RFC5730]. 1040 3.2. EPP Transform Commands 1042 EPP provides five commands to transform objects: to create 1043 an instance of an object, to delete an instance of an 1044 object, to extend the validity period of an object, 1045 to manage object sponsorship changes, and to 1046 change information associated with an object. 1048 3.2.1. EPP Command 1050 This extension defines additional elements to extend the EPP 1051 command of an object mapping like the EPP domain name mapping 1052 [RFC5731], EPP host mapping [RFC5732], and EPP contact mapping 1053 [RFC5733]. 1055 The EPP command provides a transform operation that allows a 1056 client to create an object. In addition to the EPP command elements 1057 described in an object mapping like [RFC5731], the command MAY 1058 contain a child element, as 1059 defined in Section 2.1.2, that identifies the extension namespace for 1060 the client to provide proof of verification by a Verification Service 1061 Provider (VSP). The server MAY support multiple policies for the 1062 passing of the element based on 1063 the client profile, which include: 1065 required The client MUST pass a valid 1066 element containing the 1067 required set of verification codes. If a 1068 element is not passed or the 1069 required set of verification codes is not included, the server 1070 MUST return an EPP error result code of 2306. If an invalid 1071 element is passed, the 1072 server MUST return an EPP error result code of 2005. 1073 optional The client MAY pass a valid 1074 element. If an invalid 1075 element is passed, the 1076 server MUST return an EPP error result code of 2005. 1077 not supported The client MUST NOT pass a 1078 element. If a 1079 element is passed, the 1080 server MUST return an EPP error result code of 2102. 1082 Example command to create a domain object with a 1083 verification code: 1085 C: 1086 C: 1087 C: 1088 C: 1089 C: 1091 C: domain.example 1092 C: jd1234 1093 C: sh8013 1094 C: sh8013 1095 C: 1096 C: 2fooBAR 1097 C: 1098 C: 1099 C: 1100 C: 1101 C: 1104 C: 1105 C:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z 1106 C:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht 1107 C:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD 1108 C:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp 1109 C:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 1110 C:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg 1111 C:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 1112 C:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 1113 C:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp 1114 C:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk 1115 C:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y 1116 C:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1117 C:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l 1118 C:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu 1119 C:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P 1120 C:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy 1121 C:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 1122 C:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa 1123 C:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 1124 C:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ 1125 C:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr 1126 C:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa 1127 C:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm 1128 C:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z 1129 C:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ 1130 C:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB 1131 C:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF 1132 C:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k 1133 C:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF 1134 C:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB 1135 C:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr 1136 C:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG 1137 C:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G 1138 C:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw 1139 C:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa 1140 C:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 1141 C:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr 1142 C:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ 1143 C:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n 1144 C:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF 1145 C:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH 1146 C:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB 1147 C:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj 1148 C:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w 1149 C:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK 1150 C:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi 1151 C:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK 1152 C:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB 1153 C:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi 1154 C:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC 1155 C:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz 1156 C:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr 1157 C:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W 1158 C:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy 1159 C:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts 1160 C:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt 1161 C:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn 1162 C:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE 1163 C:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp 1164 C:b25Db2RlOnNpZ25lZENvZGU+Cg== 1165 C: 1166 C: 1167 C: 1168 C: ABC-12345 1169 C: 1170 C: 1172 This extension does not add any elements to the EPP response 1173 described in the [RFC5730]. 1175 3.2.2. EPP Command 1177 This extension defines additional elements to extend the EPP 1178 command and response in the same fashion as defined for the EPP 1179 Command (Section 3.2.1). 1181 3.2.3. EPP Command 1183 This extension defines additional elements to extend the EPP 1184 command and response in the same fashion as defined for the EPP 1185 Command (Section 3.2.1). 1187 3.2.4. EPP Command 1189 This extension defines additional elements to extend the EPP 1190 command and response in the same fashion as defined for 1191 the EPP Command (Section 3.2.1). 1193 3.2.5. EPP Command 1195 This extension defines additional elements to extend the EPP 1196 command and response in the same fashion as defined for the EPP 1197 Command (Section 3.2.1). 1199 4. Formal Syntax 1201 One schema is presented here that is the EPP Verification Code 1202 Extension schema. 1204 The formal syntax presented here is a complete schema representation 1205 of the object mapping suitable for automated validation of EPP XML 1206 instances. The BEGIN and END tags are not part of the schema; they 1207 are used to note the beginning and ending of the schema for URI 1208 registration purposes. 1210 4.1. Verification Code Extension Schema 1212 BEGIN 1213 1214 1223 1224 1225 Extensible Provisioning Protocol v1.0 1226 Verification Code Extension. 1227 1228 1229 1232 1233 1237 1238 1240 1241 1245 1246 1247 1248 1249 1251 1252 1253 1254 1255 1256 1258 1259 1260 1261 1262 1264 1265 1266 1268 1270 1271 1272 1274 1275 1278 1279 1280 1283 1284 1286 1287 1288 1289 1291 1292 1293 1295 1296 1298 1299 1300 1301 1302 1303 1304 1306 1307 1309 1310 1311 1313 1316 1317 1319 1320 1321 1323 1326 1329 1330 1331 1333 1334 1335 1336 1337 1338 1339 1340 1342 1343 1344 1345 1347 1349 1350 1351 1353 1354 1355 1358 1359 1361 1362 1363 1364 1366 1368 1369 1370 1372 1373 1374 1377 1378 1380 1381 END 1383 5. IANA Considerations 1385 5.1. XML Namespace 1387 This document uses URNs to describe XML namespaces and XML schemas 1388 conforming to a registry mechanism described in [RFC3688]. 1390 Registration request for the verificationCode namespace: 1392 URI: ietf:params:xml:ns:verificationCode-1.0 1393 Registrant Contact: IESG 1394 XML: None. Namespace URIs do not represent an XML specification. 1396 Registration request for the verificationCode XML schema: 1398 URI: ietf:params:xml:ns:verificationCode-1.0 1399 Registrant Contact: IESG 1400 XML: See the "Formal Syntax" section of this document. 1402 5.2. EPP Extension Registry 1404 The EPP extension described in this document should be registered by 1405 the IANA in the EPP Extension Registry described in [RFC7451]. The 1406 details of the registration are as follows: 1408 Name of Extension: "Verification Code Extension for the Extensible 1409 Provisioning Protocol (EPP)" 1411 Document status: Standards Track 1413 Reference: (insert reference to RFC version of this document) 1415 Registrant Name and Email Address: IESG, 1417 TLDs: Any 1419 IPR Disclosure: None 1420 Status: Active 1422 Notes: None 1424 6. Implementation Status 1426 Note to RFC Editor: Please remove this section and the reference to 1427 RFC 7942 [RFC7942] before publication. 1429 This section records the status of known implementations of the 1430 protocol defined by this specification at the time of posting of this 1431 Internet-Draft, and is based on a proposal described in RFC 7942 1432 [RFC7942]. The description of implementations in this section is 1433 intended to assist the IETF in its decision processes in progressing 1434 drafts to RFCs. Please note that the listing of any individual 1435 implementation here does not imply endorsement by the IETF. 1436 Furthermore, no effort has been spent to verify the information 1437 presented here that was supplied by IETF contributors. This is not 1438 intended as, and must not be construed to be, a catalog of available 1439 implementations or their features. Readers are advised to note that 1440 other implementations may exist. 1442 According to RFC 7942 [RFC7942], "this will allow reviewers and 1443 working groups to assign due consideration to documents that have the 1444 benefit of running code, which may serve as evidence of valuable 1445 experimentation and feedback that have made the implemented protocols 1446 more mature. It is up to the individual working groups to use this 1447 information as they see fit". 1449 6.1. Verisign EPP SDK 1451 Organization: Verisign Inc. 1453 Name: Verisign EPP SDK 1455 Description: The Verisign EPP SDK includes both a full client 1456 implementation and a full server stub implementation of draft-ietf- 1457 regext-verificationcode. 1459 Level of maturity: Production 1461 Coverage: All aspects of the protocol are implemented. 1463 Licensing: GNU Lesser General Public License 1465 Contact: jgould@verisign.com 1466 URL: https://www.verisign.com/en_US/channel-resources/domain- 1467 registry-products/epp-sdks 1469 6.2. Net::DRI 1471 Organization: Dot and Co 1473 Name: Net::DRI 1475 Description: Net::DRI implements the client-side of draft-ietf- 1476 regext-verificationcode. 1478 Level of maturity: Production 1480 Coverage: All client-side aspects of the protocol are implemented. 1482 Licensing: GNU Lesser General Public License 1484 Contact: netdri@dotandco.com 1486 7. Security Considerations 1488 The mapping extension described in this document is based on the 1489 security services described by EPP [RFC5730] and protocol layers used 1490 by EPP. The security considerations described in these other 1491 specifications apply to this specification as well. 1493 XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this 1494 extension to verify that the Verification Code originated from a 1495 trusted Verification Service Provider (VSP) and that it wasn't 1496 tampered with in transit from the VSP to the client to the server. 1497 To support multiple VSP keys, the VSP certificate chain MUST be 1498 included in the elements of the Signed Code 1499 (Section 2.1.1) and MUST chain up and be verified by the server 1500 against a set of trusted certificates. 1502 It is RECOMMENDED that signed codes do not include white-spaces 1503 between the XML elements in order to mitigate risks of invalidating 1504 the digital signature when transferring of signed codes between 1505 applications takes place. 1507 Use of XML canonicalization SHOULD be used when generating the signed 1508 code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing. 1509 The size of the RSA key SHOULD be at least 2048 bits. 1511 8. References 1513 8.1. Normative References 1515 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1516 Extensions (MIME) Part One: Format of Internet Message 1517 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1518 . 1520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1521 Requirement Levels", BCP 14, RFC 2119, 1522 DOI 10.17487/RFC2119, March 1997, . 1525 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1526 DOI 10.17487/RFC3688, January 2004, . 1529 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1530 Specifications: ABNF", STD 68, RFC 5234, 1531 DOI 10.17487/RFC5234, January 2008, . 1534 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1535 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1536 . 1538 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1539 Domain Name Mapping", STD 69, RFC 5731, 1540 DOI 10.17487/RFC5731, August 2009, . 1543 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1544 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 1545 August 2009, . 1547 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1548 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1549 August 2009, . 1551 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1552 Code: The Implementation Status Section", BCP 205, 1553 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1554 . 1556 [W3C.CR-xmldsig-core2-20120124] 1557 Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, 1558 J., Solo, D., Datta, P., and F. Hirsch, "XML Signature 1559 Syntax and Processing Version 2.0", World Wide Web 1560 Consortium CR CR-xmldsig-core2-20120124, January 2012, 1561 . 1563 8.2. Informative References 1565 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1566 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1567 February 2015, . 1569 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1570 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1571 May 2017, . 1573 Appendix A. Acknowledgements 1575 The authors wish to thank the following persons for their feedback 1576 and suggestions: 1578 o Gurshabad Grover 1579 o Rick Wilhelm 1581 Appendix B. Change History 1583 B.1. Change from 00 to 01 1585 1. Fixed pendingComplaince and complaint to pendingCompliance and 1586 compliant in text. 1587 2. Fixed verificaton to verification. 1589 B.2. Change from 01 to 02 1591 1. Added support for the notApplicable status value. 1593 B.3. Change from 02 to 03 1595 1. Added regular expression pattern for the format of the 1596 verification code token value in the XML schema. 1598 B.4. Change from 03 to 04 1600 1. Ping update. 1602 B.5. Change from 04 to REGEXT 00 1604 1. Changed to regext working group draft by changing draft-gould- 1605 eppext-verificationcode to draft-ietf-regext-verificationcode. 1607 B.6. Change from REGEXT 00 to REGEXT 01 1609 1. Ping update. 1611 B.7. Change from REGEXT 01 to REGEXT 02 1613 1. Ping update. 1615 B.8. Change from REGEXT 02 to REGEXT 03 1617 1. Moved RFC 7451 to an informational reference based on a check 1618 done by the Idnits Tool. 1619 2. Replaced the IANA Registrant Contact to be "IESG". 1621 B.9. Change from REGEXT 03 to REGEXT 04 1623 1. Added the Implementation Status section. 1624 2. Revised the sentence "The data verified by the VSP MUST be stored 1625 by the VSP along with the generated verification code to address 1626 any compliance issues." to "The VSP MUST store the proof of 1627 verification and the generated verification code; and MAY store 1628 the verified data.", and added text to the Security 1629 Considerations section associated with storing the verification 1630 data, based on feedback from Gurshabad Grover. 1632 B.10. Change from REGEXT 04 to REGEXT 05 1634 1. Removed the "The Verification Service Provider (VSP) MUST store 1635 the verification data in compliance with the applicable privacy 1636 laws and regulations." sentence from the Security Considerations, 1637 based on feedback from Rick Wilhelm and agreement from Gurshabad 1638 Grover. 1639 2. Added the sentence "It is up to server policy what action to take 1640 if the verification code type is not set by the grace period." to 1641 section 2.2 "Verification Profile", to clarify what happens when 1642 the verification code grace period expires. This is based on an 1643 issue raised by Gurshabad Grover at the IETF-103 REGEXT meeting. 1645 Author's Address 1646 James Gould 1647 VeriSign, Inc. 1648 12061 Bluemont Way 1649 Reston, VA 20190 1650 US 1652 Email: jgould@verisign.com 1653 URI: http://www.verisign.com