Internet Engineering Task Force X. Jiagui Internet-Draft Teleinfo Intended status: Informational J. Gould Expires: April 22, 2016 VeriSign, Inc. L. Hongyan Teleinfo October 20, 2015 Extensible Provisioning Protocol (EPP) China Name Verification Mapping draft-xie-eppext-nv-mapping-01 Abstract This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of Name Verification (NV) stored in a shared central repository in China. Specified in XML, the mapping defines EPP command syntax and semantics as applied to name verification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Jiagui, et al. Expires April 22, 2016 [Page 1] Internet-Draft EPP NV Mapping October 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions and Object Attributes . . . . . . . . . . . . . . 4 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Object Attributes . . . . . . . . . . . . . . . . . . . . 4 3.3. Name Verification Proofs . . . . . . . . . . . . . . . . 5 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 4.1.3. EPP Command . . . . . . . . . . . . . . . 16 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16 4.2.1. EPP Command . . . . . . . . . . . . . . . . 16 4.2.2. EPP Command . . . . . . . . . . . . . . . . 22 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 22 4.2.4. EPP Command . . . . . . . . . . . . . . . 22 4.2.5. EPP Command . . . . . . . . . . . . . . . . 22 4.3. Offline Review of Requested Actions . . . . . . . . . . . 24 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Internationalization Considerations . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 33 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 34 8. Security considerations . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. draft-xie-eppext-nv-mapping-00: Version 00 . . . . . . . 35 10.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 35 11. Normative References . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Jiagui, et al. Expires April 22, 2016 [Page 2] Internet-Draft EPP NV Mapping October 2015 1. Introduction When creating a domain name which will be stored in a shared central repository, some registry administrative organizations require the verification of the domain name and the real name based on legal or policy requirements. The domain name verification, means to verify the domain label is in compliance with laws, rules and regulations. The real name verification, means to verify that the registrant really exists and is authorized to register a domain name. The verification of this document meets the requirements in China, but MAY be applicable outside of China. In order to meet above requirements of the domain name registration, this document describes the Extensible Provisioning Protocol (EPP) Name Verification (NV) Mapping. This document is specified using the Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "nv-1.0" in this document is used as an abbreviation for urn:ietf:params:xml:ns:nv-1.0. The XML namespace prefix "nv" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this specification. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. Jiagui, et al. Expires April 22, 2016 [Page 3] Internet-Draft EPP NV Mapping October 2015 3. Definitions and Object Attributes 3.1. Definitions The following definitions are used in this document: o Domain Name Verification(DNV), represents the verification of the domain's label is in compliance with laws, rules and regulations. o Real Name Verification(RNV), represents the verification of the registrant(real name) is in compliance with laws, rules and regulations. o Name Verification(NV), represents DNV, RNV or both of them. o Verification Service Provider(VSP), collects the proof of materials for Name Verification(NV) and performs the verification. o Verification Code, which is described in [I-D.gould-eppext-verificationcode] ,is a formatted token, referred to as the Verification Code Token, that is digitally signed by a Verification Service Provider (VSP) using XML Signature in "W3C.CR-xmldsig-core2-20120124". o Signed Code, which is described in [I-D.gould-eppext-verificationcode], is the XML Signature format of the Verification Code. o Encoded Signed Code, which is described in [I-D.gould-eppext-verificationcode], is the "base64" encoded XML Signature format of the Verification Code. o Prohibited Name(PN), is a domain label that is prohibited from registration. o Restricted Name(RN), is a domain label that is restricted from registration. Additional information is needed during Domain Name Verification(DNV) to authorize the registration of a Restricted Name. 3.2. Object Attributes An EPP NV object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references. Jiagui, et al. Expires April 22, 2016 [Page 4] Internet-Draft EPP NV Mapping October 2015 o Status Values. A NV object MUST always have one associated status value. The Status value can be set only by the server. The status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the object. The status of an object MAY change as a result of an action performed by a server operator. Status Value Descriptions: * pendingCompliant. The object verification is not complete and is pending completion. Please refer to Section 4.3 for details on handling offline review of NV objects with the pendingComplaint status. * compliant. The object is in compliance with the policy. * nonCompliant. The object is not in compliance with the policy. o Dates and Times. Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters. o Authorization Information. Authorization information is associated with NV objects to facilitate query operations. Authorization information is assigned when a NV object is created, and it might be updated in the future. This specification describes password-based authorization information, though other mechanisms are possible. 3.3. Name Verification Proofs When performing name verification, some Verification Service Providers(VSP) MAY need to collect the proof of materials to verify the real name of a registrant. The proof of materials is defined with the following enumerated values: o "poc" for Proof of Citizen(POC). The POC represents the citizen's identification card(ID) material. o "poe" for Proof of Enterprise(POE). The POE represents the Organization Code Certificate(OCC) or Business License(BL) material. o "poot" for Proof of Other Types(POOT). The POOT represents other certificate materials except the POC and POE. Jiagui, et al. Expires April 22, 2016 [Page 5] Internet-Draft EPP NV Mapping October 2015 4. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing NV via EPP. 4.1. EPP Query Commands EPP provides three commands to retrieve NV information: determine if an object is known to the server, to retrieve detailed information associated with an object, and to retrieve object transfer status information. 4.1.1. EPP Command The EPP command is used to determine if the domain's label can be used to create a DNV object. It provides a hint that allows a client to anticipate the success or failure of creating a DNV object using the command. In addition to the standard EPP command elements, the command MUST contain a element that identifies the nv namespace. The element contains the following child elements: o One or more elements that contain the domain labels to be queried. Example command: C: C: C: C: C: C: example1 C: example2 C: example3 C: C: C: ABC-12345 C: C: When a command has been processed successfully, the EPP element MUST contain a child element that identifies the NV namespace. The element contains one or more elements that contain the following child elements: Jiagui, et al. Expires April 22, 2016 [Page 6] Internet-Draft EPP NV Mapping October 2015 o A element that contains the queried domain label. This element MUST contain an "avail" attribute whose value indicates object availability (can it be created or not) at the moment the command was completed. A value of "1" or "true" means that the object can be created. A value of "0" or "false" means that the object can not be created. This element SHOULD contain a "restricted" attribute whose value indicates this name is a RN or not, with a default value of "0". A value of "1" or "true" means that the object is a RN Name. A value of "0" or "false" means that the object is not restricted. o An OPTIONAL element that MAY be provided when an object cannot be created. If present, this element contains server-specific text to help explain why the object cannot be created. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English). Jiagui, et al. Expires April 22, 2016 [Page 7] Internet-Draft EPP NV Mapping October 2015 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: S: example1 S: S: S: example2 S: In Prohibited Lists. S: S: S: example3 S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: An EPP error response MUST be returned if a command cannot be processed for any reason. 4.1.2. EPP Command The EPP command is used to retrieve information associated with a NV object. The response to this command MAY vary depending on the identity of the querying client, and server policy towards unauthorized clients. If the querying client is the sponsoring client, all available information MUST be returned. If the querying client is not the sponsoring client but the client provides valid authorization information, all available information MUST be returned. If the querying client is not the sponsoring client and the client does not provide valid authorization information, server policy determines which OPTIONAL elements are returned. Jiagui, et al. Expires April 22, 2016 [Page 8] Internet-Draft EPP NV Mapping October 2015 In addition to the standard EPP command elements, the command MUST contain a element that identifies the NV namespace. The element contains the following child elements: o A element that contains the Verification Code Token value. An "type" attribute MUST be used to identify the type of the query(Signed Code or Input Data). If the type is "signedCode", the successful response of the server MUST be the Signed Code of the verification code. If the type is "input", the successful response of the server MUST be the verification input data and the verification status. o An OPTIONAL element that contains authorization information associated with the NV object. If this element is not provided or if the authorization information is invalid, server policy determines if the command is rejected or if response information will be returned to the client. Jiagui, et al. Expires April 22, 2016 [Page 9] Internet-Draft EPP NV Mapping October 2015 Example command to query the signed code: C: C: C: C: C: C: abc-123 C: C: C: ABC-12345 C: C: Example command to query the input data: C: C: C: C: C: C: abc-123 C: C: C: ABC-12345 C: C: Example command with authorization information: C: C: C: C: C: C: abc-123 C: C: 2fooBAR C: C: C: C: ABC-12345 C: C: Jiagui, et al. Expires April 22, 2016 [Page 10] Internet-Draft EPP NV Mapping October 2015 When an command has been processed successfully, the EPP element MUST contain a child element that identifies the nv namespace. The element has two forms based on the query type provided in the command: the Signed Code Form and the Input Form. The child element of the element is defined for each form. The Signed Code Form is returned when the command "type" attribute is set to "signedCode". The element is used for the Signed Code Form that contains the following child elements: o A element that contains the Verification Code Token value of the signed code with the "type" attribute to indicate the type of NV object. The "type" attribute value of "domain" indicates a DNV object and "real-name" indicates a RNV object. o An OPTIONAL element that contains the current status using the status values defined in Section 3.2. o A element include: * A element that is a "base64" encoded form of the digitally signed as defined in [I-D.gould-eppext-verificationcode]. Example response of a Signed Code: S: S: S: S: S: Command completed successfully S: S: S: S: S: abc-123 S: S: S: 2fooBAR S: S: S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 Jiagui, et al. Expires April 22, 2016 [Page 11] Internet-Draft EPP NV Mapping October 2015 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W Jiagui, et al. Expires April 22, 2016 [Page 12] Internet-Draft EPP NV Mapping October 2015 S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp S:b25Db2RlOnNpZ25lZENvZGU+Cg== S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: The Input Code Form is returned when the command "type" attribute is set to "input". The element is used for the Input Form and contains a choice of two different child elements dependent on the type of NV object that matches the in the command. The child element is used for a DNV object and the child element is used for a RNV object. The element is used for a DNV object and contains the following child elements: o A element that contains the label of the domain. o An OPTIONAL element containing the Verification Code Token value of a RNV object used for verification of a Restricted Name. Jiagui, et al. Expires April 22, 2016 [Page 13] Internet-Draft EPP NV Mapping October 2015 Example response of a DNV: S: S: S: S: S: Command completed successfully S: S: S: S: S: S: example S: S: S: 2fooBAR S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: The element is used for a RNV object. The "role" attribute MUST be used to identify the role of the RNV object with the possible values of "person" or "org". The element contains the following child elements: o A element that contains the full name of the contact. o A element that contains the citizen or the organization ID of the contact. o A element that contains the proof material type of the contact based on the enumerated values defined in Name Verification Proofs (Section 3.3). o Zero or more elements that contains the following child elements: * A element contains the type of the file. Jiagui, et al. Expires April 22, 2016 [Page 14] Internet-Draft EPP NV Mapping October 2015 * A element contains the "base64" encoded content of the file. Example response of a RNV person: S: S: S: S: S: Command completed successfully S: S: S: S: S: S: John Xie S: 1234567890 S: poc S: S: jpg S: EABQRAQAAAAAAAAAAAAAAAAAAAAD S: S: S: S: S: 2fooBAR S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Example response of a RNV organization: S: S: S: S: S: Command completed successfully S: S: S: Jiagui, et al. Expires April 22, 2016 [Page 15] Internet-Draft EPP NV Mapping October 2015 S: S: S: John Xie S: 1234567890 S: poe S: S: jpg S: EABQRAQAAAAAAAAAAAAAAAAAAAAD S: S: S: S: S: 2fooBAR S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: A server with a different information-return policy MAY provide less information in a response for an unauthorized client. An EPP error response MUST be returned if an command cannot be processed for any reason. 4.1.3. EPP Command Transfer semantics do not apply to Name Verification (NV) objects, so there is no mapping defined for the EPP command. 4.2. EPP Transform Commands EPP provides five commands to transform NV objects: to create an instance of an object, to delete an instance of an object, to extend the validity period of an object, to manage object sponsorship changes, and to change information associated with an object. 4.2.1. EPP Command The EPP command provides a transform operation that allows a client to create an NV object. In addition to the standard EPP command elements, the command MUST contain a Jiagui, et al. Expires April 22, 2016 [Page 16] Internet-Draft EPP NV Mapping October 2015 element that identifies the NV namespace. The elements contains a choice of two different child elements dependent on the type of NV object to create. The child element is used to create a DNV object and the child element is used to create a RNV object. AN element contains authorization information to be associated with the NV object. o The element is used for a DNV object and contains the following child elements: * A element that contains the label of the domain. * An OPTIONAL element containing the Verification Code Token value of a RNV object used for verification of a Restricted Name. o The element is used for a RNV object. The "role" attribute MUST be used to identify the role of the RNV object with the possible values of "person" or "org". The element contains the following child elements: * A element that contains the full name of the contact. * A element that contains the citizen or the organization ID of the contact. * A element that contains the proof material type of the contact based on the enumerated values defined in Name Verification Proofs (Section 3.3). * Zero or more elements that contains the following child elements: + A element contains the type of the file. + A element contains the "base64" encoded content of the file. Example command for a DNV object: C: C: C: C: C: C: C: example C: Jiagui, et al. Expires April 22, 2016 [Page 17] Internet-Draft EPP NV Mapping October 2015 C: C: 2fooBAR C: C: C: C: ABC-12345 C: C: Example command for a RNV person object: C: C: C: C: C: C: C: John Xie C: 1234567890 C: poe C: C: jpg C: EABQRAQAAAAAAAAAAAAAAAAAAAAD C: C: C: C: C: 2fooBAR C: C: C: C: ABC-12345 C: C: Example command for an RNV organization: C: C: C: C: C: C: C: John Xie C: 1234567890 C: poe C: C: jpg Jiagui, et al. Expires April 22, 2016 [Page 18] Internet-Draft EPP NV Mapping October 2015 C: EABQRAQAAAAAAAAAAAAAAAAAAAAD C: C: C: C: C: 2fooBAR C: C: C: C: ABC-12345 C: C: When a command has been processed successfully, the EPP element MUST contain a child element that identifies the nv namespace. element contains the either a element on success or a element on failure. o The element contains the following child elements: * A element that contains the id of the verification code with the required "type" attribute that defines the type of the verification code. * A element that contains the current status using the status values defined in Section 3.2. * A element that contains the date and time of nv object creation. * A element include: + A element that is a "base64" encoded form of the digitally signed as defined in [I-D.gould-eppext-verificationcode]. o The element contains the following child elements: * A element that contains the current status using the status values defined in Section 3.2. * A element containing a human-readable description of the reason of the failure. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). Example response of success: Jiagui, et al. Expires April 22, 2016 [Page 19] Internet-Draft EPP NV Mapping October 2015 S: S: S: S: S: Command completed successfully S: S: S: S: S: abc-123 S: S: 2015-08-17T22:00:00.0Z S: S:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z S:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht S:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD S:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp S:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 S:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg S:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 S:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 S:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp S:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk S:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y S:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl S:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l S:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu S:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P S:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy S:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 S:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa S:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 S:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ S:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr S:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa S:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm S:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z S:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ S:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB S:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF S:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k S:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF S:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB S:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr S:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG S:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G S:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw S:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa Jiagui, et al. Expires April 22, 2016 [Page 20] Internet-Draft EPP NV Mapping October 2015 S:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 S:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr S:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ S:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n S:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF S:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH S:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB S:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj S:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w S:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK S:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi S:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK S:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB S:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi S:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC S:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz S:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr S:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W S:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy S:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts S:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt S:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn S:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE S:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp S:b25Db2RlOnNpZ25lZENvZGU+Cg== S: S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: Example response of failed: S: S: S: S: S: Command completed successfully S: S: S: S: S: Jiagui, et al. Expires April 22, 2016 [Page 21] Internet-Draft EPP NV Mapping October 2015 S: S: The name of the object is not correct. S: S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if a command cannot be processed for any reason. 4.2.2. EPP Command Delete semantics do not apply to Name Verification (NV) objects, so there is no mapping defined for the EPP command. 4.2.3. EPP Command Renew semantics do not apply to Name Verification (NV) objects, so there is no mapping defined for the EPP command. 4.2.4. EPP Command Transfer semantics do not apply to Name Verification (NV) objects, so there is no mapping defined for the EPP command. 4.2.5. EPP Command The EPP command provides a transform operation that allows a client to modify the attributes of a NV object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the NV namespace. The element contains the following child elements: o A element that contains the code of the a NV object to be updated. o A element that contains object attribute values to be changed. A element contains the following child elements: Jiagui, et al. Expires April 22, 2016 [Page 22] Internet-Draft EPP NV Mapping October 2015 o A element that contains authorization information associated with the NV object. This mapping includes a password- based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas. Example command: C: C: C: C: C: C: abc-123 C: C: C: 2BARfoo C: C: C: C: C: ABC-12345 C: C: When an command has been processed successfully, a server MUST respond with an EPP response with no element. Example response: S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: An EPP error response MUST be returned if an command cannot be processed for any reason. Jiagui, et al. Expires April 22, 2016 [Page 23] Internet-Draft EPP NV Mapping October 2015 4.3. Offline Review of Requested Actions Commands are processed by a server in the order they are received from a client. Though an immediate response confirming receipt and processing of the command is produced by the server, a server operator MAY perform an offline review of requested transform commands before completing the requested action. In such situations, the response from the server MUST clearly note that the transform command has been received and processed but that the requested action is pending. The status of the corresponding object MUST clearly reflect processing of the pending action. The server MUST notify the client when offline processing of the action has been completed. Examples describing a command that requires offline review are included here. Note the result code and message returned in response to the command. S: S: S: S: S: Command completed successfully; action pending S: S: S: S: S: abc-123 S: S: 2015-09-03T22:00:00.0Z S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S: The status of the NV object after returning this response MUST include "pendingCompliant". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the command or by using an out-of-band mechanism to inform the client of the outcome of the review. Jiagui, et al. Expires April 22, 2016 [Page 24] Internet-Draft EPP NV Mapping October 2015 The service message MUST contain text that describes the notification in the child element of the response element. In addition, the EPP element MUST contain a child element that identifies the NV namespace. The element contains the following child elements: A element that contains the id of the verification code with the required "type" attribute that defines the type of the verification code. A element that contains the current status descriptors associated with the NV. A element containing a human-readable description of the result. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). A element that contains the date and time describing when review of the requested action was completed. Jiagui, et al. Expires April 22, 2016 [Page 25] Internet-Draft EPP NV Mapping October 2015 Example "review completed" service message: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2015-09-04T22:01:00.0Z S: Pending action completed successfully. S: S: S: S: abc-123 S: S: The object has passed verification, S: signed code was generated. S: 2015-09-04T22:00:00.0Z S: S: S: S: BCD-23456 S: 65432-WXY S: S: S: 5. Formal Syntax An EPP object NV mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. BEGIN Extensible Provisioning Protocol v1.0 Name Verification provisioning schema. Jiagui, et al. Expires April 22, 2016 [Page 27] Internet-Draft EPP NV Mapping October 2015 Jiagui, et al. Expires April 22, 2016 [Page 28] Internet-Draft EPP NV Mapping October 2015 Jiagui, et al. Expires April 22, 2016 [Page 29] Internet-Draft EPP NV Mapping October 2015 Jiagui, et al. Expires April 22, 2016 [Page 32] Internet-Draft EPP NV Mapping October 2015 END 6. Internationalization Considerations EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED. As an extension of the EPP, the elements, element content described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension. 7. IANA Considerations 7.1. XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA is requested to assignment the following two URI. Registration request for the NV namespace: o URI: urn:ietf:params:xml:ns:nv-1.0 Jiagui, et al. Expires April 22, 2016 [Page 33] Internet-Draft EPP NV Mapping October 2015 o Registrant Contact: See the "Author's Address" section of this document. o XML: None. Namespace URI does not represent an XML specification. Registration request for the NV XML schema: o URI: urn:ietf:params:xml:schema:nv-1.0 o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. 7.2. EPP Extension Registry The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows: Name of Extension: Extensible Provisioning Protocol (EPP) China Name Verification Mapping Document status: Informational Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Notes: None 8. Security considerations Verification Code Tokens are digitally signed using XML Signature technology. The security considerations described in Section 12 of the W3C XML Signature Syntax and Processing Candidate Recommendation [W3C.CR-xmldsig-core2-20120124] apply to this specification as well. The object mapping described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730] or those caused by the protocol layers used by EPP. Jiagui, et al. Expires April 22, 2016 [Page 34] Internet-Draft EPP NV Mapping October 2015 9. Acknowledgements The authors especially thank the author of [RFC5730]. Useful comments and contributions were made by TBD. 10. Change History RFC Editor: Please remove this section. 10.1. draft-xie-eppext-nv-mapping-00: Version 00 o First draft. 10.2. Change from 01 to 02 1. Made the element of the panDataType and pendingType require the "type" attribute in the XML schema. 2. Fixed the XML schema to include the OPTIONAL element. 3. Added the support for the OPTIONAL "lang" attribute for the element of the and elements. 11. Normative References [I-D.gould-eppext-verificationcode] Gould, J., "Verification Code Extension for the Extensible Provisioning Protocol (EPP)", draft-gould-eppext- verificationcode-00 (work in progress), September 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, February 2015. Jiagui, et al. Expires April 22, 2016 [Page 35] Internet-Draft EPP NV Mapping October 2015 [W3C.CR-xmldsig-core2-20120124] Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and E. Simon, ""XML Signature Syntax and Processing Version 2.0", W3C Candidate Recommendation 24 January 2012", January 2012, . [W3C.REC-xml-20040204] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204", February 2004, . [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, ""XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema- 1-20041028", October 2004, . [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028", October 2004, . Authors' Addresses Xie Jiagui Teleinfo 1#-21,gaolizhang Street,Haidian District Beijing, Beijing 100095 China Phone: +86 10 5884 6931 Email: xiejiagui@teleinfo.cn James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisign.com Jiagui, et al. Expires April 22, 2016 [Page 36] Internet-Draft EPP NV Mapping October 2015 Liu Hongyan Teleinfo 1#-21,gaolizhang Street,Haidian District Beijing, Beijing 100095 China Phone: +86 10 5884 6931 Email: liuhongyan@teleinfo.cn Jiagui, et al. Expires April 22, 2016 [Page 37]