Verification Code Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-verificationcode-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | James Gould | ||
| Last updated | 2017-05-01 (Latest revision 2017-04-17) | ||
| Replaces | draft-gould-eppext-verificationcode | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Adam Roach | ||
| Send notices to | (None) |
draft-ietf-regext-verificationcode-01
Gould Expires October 19, 2017 [Page 12] Internet-Draft verificationCode April 2017 Example <info> domain command with the <verificationCode:info> extension to retrieve the verification information for the domain "domain.example", using the profiles associated with the client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>domain.example</domain:name> C: </domain:info> C: </info> C: <extension> C: <verificationCode:info C: xmlns:verificationCode= C: "urn:ietf:params:xml:ns:verificationCode-1.0"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp> Example <info> domain command with the <verificationCode:info> extension to retrieve the verification information for the domain "domain.example", using the profiles associated with the client and with the authorization information to retrieve the verification codes from the non-sponsoring client: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>domain.example</domain:name> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:info> C: </info> C: <extension> C: <verificationCode:info C: xmlns:verificationCode= C: "urn:ietf:params:xml:ns:verificationCode-1.0"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp> Gould Expires October 19, 2017 [Page 13] Internet-Draft verificationCode April 2017 Example <info> domain command with the <verificationCode:info> extension to retrieve the verification information for the domain "domain.example", using the the "sample" profile: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>domain.example</domain:name> C: </domain:info> C: </info> C: <extension> C: <verificationCode:info C: xmlns:verificationCode= C: "urn:ietf:params:xml:ns:verificationCode-1.0" C: profile="sample"/> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp> If the query was successful, the server replies with a <verificationCode:infData> element along with the regular EPP <resData>. The <verificationCode:infData> element contains the following child elements: <verificationCode:status> The status of the verification for the object, using all of the verification profiles assigned to the client. There are four possible values for the status: notApplicable The status is not applicable to the client since there is no assigned verification profile. nonCompliant The object is non-compliant according to the verification profiles. If at least one of the profiles is "nonCompliant", the object is "nonCompliant". pendingCompliance The object is not in compliance with the verification profiles, but has a grace period to set the required set of verification codes, as reflected by the due date of the verification code type. If at least one of the profiles is "pendingCompliance" and none of the profiles is "nonCompliant", the object is "pendingCompliance". compliant The object is compliant with the verification profiles. If All of the profiles for the object are "compliant" or if the object has no assignd profiles, the object is "compliant". Gould Expires October 19, 2017 [Page 14] Internet-Draft verificationCode April 2017 <verificationCode:profile> Zero or more OPTIONAL <verificationCode:profile> elements that defines the verification status of the object based on the profile. The required "name" attribute defines the name of the profile. The <verificationCode:profile> element contains the following child elements: <verificationCode:status> The status of the verification for the object and the profile. There are four possible values for the status: notApplicable The profile status is not applicable to the client based on the assigned verification profiles or the profile specified. nonCompliant The object is non-compliant according to the verification profile. pendingCompliance The object is not in compliance with the verification profile, but has a grace period to set the required set of verification codes, as reflected by the due date of the verification code type. compliant The object is compliant with the verification profile. <verificationCode:missing> OPTIONAL list of missing verification code types. The <verificationCode:missing> element is returned only if there is at least one missing verification code type and based on server policy. The <verificationCode:missing> element contains the following child elements: <verificationCode:code> One or more <verificationCode:code> elements that is empty with the REQUIRED "type" attribute that indicates the verification code type and the REQUIRED "due" attribute that indicates when the verification code type was or is due. Past due verification code types will result in the <verificationCode:status> element being set to "nonCompliant". <verificationCode:set> OPTIONAL list of set verification codes. The <verificationCode:set> element is returned only if there is at least one set verification code. The <verificationCode:set> element contains the following child elements: Gould Expires October 19, 2017 [Page 15] Internet-Draft verificationCode April 2017 <verificationCode:code> One or more <verificationCode:code> elements containing the verification code with a REQUIRED "type" attribute that indicates the code type and a REQUIRED "date" attribute that indicates when the verification code was set. The inclusion of the code value is up server policy, so if the server determines that the code value cannot be exposed to a non-sponsoring client, the <verificationCode:code> element MUST be empty. Example <info> domain response using the <verificationCode:infData> extension for a compliant domain using the "sample" profile, and with the two verification codes, from the sponsoring or authorized client: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:profile name="sample"> S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:set> S: <verificationCode:code type="domain" Gould Expires October 19, 2017 [Page 16] Internet-Draft verificationCode April 2017 S: date="2010-04-03T22:00:00.0Z">1-abc333 S: </verificationCode:code> S: <verificationCode:code type="registrant" S: date="2010-04-03T22:00:00.0Z">1-abc444 S: </verificationCode:code> S: </verificationCode:set> S: </verificationCode:profile> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> Example <info> domain response using the <verificationCode:infData> extension for a compliant domain using the "sample" profile, and with the two verification codes, from the sponsoring or authorized client that also includes codes set for the "sample2" profile: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> Gould Expires October 19, 2017 [Page 17] Internet-Draft verificationCode April 2017 S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:profile name="sample"> S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:set> S: <verificationCode:code type="domain" S: date="2010-04-03T22:00:00.0Z">1-abc333 S: </verificationCode:code> S: <verificationCode:code type="registrant" S: date="2010-04-03T22:00:00.0Z">1-abc444 S: </verificationCode:code> S: </verificationCode:set> S: </verificationCode:profile> S: <verificationCode:profile name="sample2"> S: <verificationCode:status>notApplicable S: </verificationCode:status> S: <verificationCode:set> S: <verificationCode:code type="domain" S: date="2010-04-03T22:00:00.0Z">2-abc555 S: </verificationCode:code> S: </verificationCode:set> S: </verificationCode:profile> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> Gould Expires October 19, 2017 [Page 18] Internet-Draft verificationCode April 2017 Example <info> domain response using the <verificationCode:infData> extension for a compliant domain using the "sample" profile, and with the two verification code types, from the non-sponsoring client: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:profile name="sample"> S: <verificationCode:status>compliant S: </verificationCode:status> S: <verificationCode:set> S: <verificationCode:code type="domain" S: date="2010-04-03T22:00:00.0Z"/> S: <verificationCode:code type="registrant" S: date="2010-04-03T22:00:00.0Z"/> S: </verificationCode:set> S: </verificationCode:profile> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> Gould Expires October 19, 2017 [Page 19] Internet-Draft verificationCode April 2017 Example <info> domain response using the <verificationCode:infData> extension for a non-compliant domain using the "sample" profile, and with the verification code types missing along with their due dates: Gould Expires October 19, 2017 [Page 20] Internet-Draft verificationCode April 2017 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="serverHold"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> S: <verificationCode:status>nonCompliant S: </verificationCode:status> S: <verificationCode:profile name="sample"> S: <verificationCode:status>nonCompliant S: </verificationCode:status> S: <verificationCode:missing> S: <verificationCode:code S: type="domain" S: due="2010-04-03T22:00:00.0Z"/> S: <verificationCode:code S: type="registrant" S: due="2010-04-08T22:00:00.0Z"/> S: </verificationCode:missing> S: </verificationCode:profile> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> Example <info> domain response using the <verificationCode:infData> Gould Expires October 19, 2017 [Page 21] Internet-Draft verificationCode April 2017 extension for a pending compliance domain using the "sample" profile, with the verification code type missing along with the due date, and with set verification code: Gould Expires October 19, 2017 [Page 22] Internet-Draft verificationCode April 2017 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> S: <verificationCode:status>pendingCompliance S: </verificationCode:status> S: <verificationCode:profile name="sample"> S: <verificationCode:status>pendingCompliance S: </verificationCode:status> S: <verificationCode:missing> S: <verificationCode:code S: type="registrant" S: due="2010-04-08T22:00:00.0Z"/> S: </verificationCode:missing> S: <verificationCode:set> S: <verificationCode:code type="domain" S: date="2010-04-03T22:00:00.0Z">1-abc333 S: </verificationCode:code> S: </verificationCode:set> S: </verificationCode:profile> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> Gould Expires October 19, 2017 [Page 23] Internet-Draft verificationCode April 2017 Example <info> domain response using the <verificationCode:infData> extension for a client that does not have a verification profile assigned: S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>domain.example</domain:name> S: <domain:roid>DOMAIN-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:clID>ClientX</domain:clID> S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>2010-04-03T22:00:00.0Z S: </domain:crDate> S: <domain:exDate>2015-04-03T22:00:00.0Z S: </domain:exDate> S: </domain:infData> S: </resData> S: <extension> S: <verificationCode:infData S: xmlns:verificationCode= S: "urn:ietf:params:xml:ns:verificationCode-1.0"> S: <verificationCode:status>notApplicable S: </verificationCode:status> S: </verificationCode:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp> 3.1.3. EPP <transfer> Command This extension does not add any elements to the EPP <transfer> query command or <transfer> response described in the [RFC5730]. Gould Expires October 19, 2017 [Page 24] Internet-Draft verificationCode April 2017 3.2. EPP Transform Commands EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object. 3.2.1. EPP <create> Command This extension defines additional elements to extend the EPP <create> command of an object mapping like the EPP domain name mapping [RFC5731], EPP host mapping [RFC5732], and EPP contact mapping [RFC5733]. The EPP <create> command provides a transform operation that allows a client to create an object. In addition to the EPP command elements described in an object mapping like [RFC5731], the command MAY contain a child <verificationCode:encodedSignedCode> element, as defined in Section 2.1.2, that identifies the extension namespace for the client to provide proof of verification by a Verification Service Provider (VSP). The server MAY support multiple policies for the passing of the <verificationCode:encodedSignedCode> element based on the client profile, which include: required The client MUST pass a valid <verificationCode:encodedSignedCode> element containing the required set of verification codes. If a <verificationCode:encodedSignedCode> element is not passed or the required set of verification codes is not included, the server MUST return an EPP error result code of 2306. If an invalid <verificationCode:encodedSignedCode> element is passed, the server MUST return an EPP error result code of 2005. optional The client MAY pass a valid <verificationCode:encodedSignedCode> element. If an invalid <verificationCode:encodedSignedCode> element is passed, the server MUST return an EPP error result code of 2005. not supported The client MUST NOT pass a <verificationCode:encodedSignedCode> element. If a <verificationCode:encodedSignedCode> element is passed, the server MUST return an EPP error result code of 2102. Example <create> command to create a domain object with a verification code: C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> Gould Expires October 19, 2017 [Page 25] Internet-Draft verificationCode April 2017 C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>domain.example</domain:name> C: <domain:registrant>jd1234</domain:registrant> C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="tech">sh8013</domain:contact> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <extension> C: <verificationCode:encodedSignedCode C: xmlns:verificationCode= C: "urn:ietf:params:xml:ns:verificationCode-1.0"> C: <verificationCode:code> C:ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z C:OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht C:bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD C:b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp C:ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3 C:dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg C:PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53 C:My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0 C:aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp C:Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk C:Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y C:aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl C:ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l C:dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu C:YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P C:UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy C:ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0 C:UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa C:Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3 C:amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ C:bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr C:CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa C:d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm C:SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z C:VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+ C:CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB C:ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF C:d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k C:bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF C:eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB C:d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr Gould Expires October 19, 2017 [Page 26] Internet-Draft verificationCode April 2017 C:R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG C:UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G C:c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw C:QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa C:cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2 C:NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr C:MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ C:ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n C:WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF C:QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH C:Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB C:Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj C:SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w C:LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK C:VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi C:R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK C:SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB C:Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi C:bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC C:MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz C:REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr C:aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W C:N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy C:aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts C:L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt C:TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn C:UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE C:YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp C:b25Db2RlOnNpZ25lZENvZGU+Cg== C: </verificationCode:code> C: </verificationCode:encodedSignedCode> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp> This extension does not add any elements to the EPP <create> response described in the [RFC5730]. 3.2.2. EPP <delete> Command This extension defines additional elements to extend the EPP <delete> command and response in the same fashion as defined for the EPP <create> Command (Section 3.2.1). Gould Expires October 19, 2017 [Page 27] Internet-Draft verificationCode April 2017 3.2.3. EPP <renew> Command This extension defines additional elements to extend the EPP <renew> command and response in the same fashion as defined for the EPP <create> Command (Section 3.2.1). 3.2.4. EPP <transfer> Command This extension defines additional elements to extend the EPP <transfer> command and response in the same fashion as defined for the EPP <create> Command (Section 3.2.1). 3.2.5. EPP <update> Command This extension defines additional elements to extend the EPP <update> command and response in the same fashion as defined for the EPP <create> Command (Section 3.2.1). 4. Formal Syntax One schema is presented here that is the EPP Verification Code Extension schema. 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. 4.1. Verification Code Extension Schema BEGIN <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace= "urn:ietf:params:xml:ns:verificationCode-1.0" xmlns:verificationCode= "urn:ietf:params:xml:ns:verificationCode-1.0" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <annotation> <documentation> Extensible Provisioning Protocol v1.0 Verification Code Extension. </documentation> </annotation> Gould Expires October 19, 2017 [Page 28] Internet-Draft verificationCode April 2017 <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/> <!-- Abstract signed code for substitution --> <element name="abstractSignedCode" type="verificationCode:abstractSignedCodeType" abstract="true"/> <!-- Empty type for use in extending for a signed code --> <complexType name="abstractSignedCodeType"/> <!-- Definition of concrete signed code --> <element name="signedCode" type="verificationCode:signedCodeType" substitutionGroup="verificationCode:abstractSignedCode"/> <complexType name="signedCodeType"> <complexContent> <extension base="verificationCode:abstractSignedCodeType"> <sequence> <element name="code" type="verificationCode:verificationCodeType"/> <element ref="dsig:Signature"/> </sequence> <attribute name="id" type="ID" use="required"/> </extension> </complexContent> </complexType> <simpleType name="verificationCodeValueType"> <restriction base="token"> <pattern value="\d+-[A-Za-z0-9]+"/> </restriction> </simpleType> <complexType name="verificationCodeType"> <simpleContent> <extension base= "verificationCode:verificationCodeValueType"> <attribute name="type" type="token" use="required"/> </extension> </simpleContent> </complexType> <!-- Definition of an encoded signed code --> <element name="encodedSignedCode" type="verificationCode:encodedSignedCodeListType"/> Gould Expires October 19, 2017 [Page 29] Internet-Draft verificationCode April 2017 <complexType name="encodedSignedCodeListType"> <sequence> <element name="code" type="verificationCode:encodedSignedCodeType" minOccurs="1" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="encodedSignedCodeType"> <simpleContent> <extension base="token"> <attribute name="encoding" type="token" default="base64"/> </extension> </simpleContent> </complexType> <!-- info command extension elements --> <element name="info" type="verificationCode:infoType"/> <complexType name="infoType"> <simpleContent> <extension base="token"> <attribute name="profile" type="token"/> </extension> </simpleContent> </complexType> <!-- info response extension elements --> <element name="infData" type="verificationCode:infDataType"/> <complexType name="infDataType"> <sequence> <element name="status" type="verificationCode:statusEnum"/> <element name="profile" type="verificationCode:profileDataType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="profileDataType"> <sequence> <element name="status" type="verificationCode:statusEnum"/> <element name="missing" type="verificationCode:missingCodes" Gould Expires October 19, 2017 [Page 30] Internet-Draft verificationCode April 2017 minOccurs="0"/> <element name="set" type="verificationCode:codesType" minOccurs="0"/> </sequence> <attribute name="name" type="token"/> </complexType> <simpleType name="statusEnum"> <restriction base="token"> <enumeration value="notApplicable"/> <enumeration value="nonCompliant"/> <enumeration value="pendingCompliance"/> <enumeration value="compliant"/> </restriction> </simpleType> <complexType name="missingVerificationCode"> <simpleContent> <extension base="token"> <attribute name="type" type="token" use="required"/> <attribute name="due" type="dateTime" use="required"/> </extension> </simpleContent> </complexType> <complexType name="missingCodes"> <sequence> <element name="code" type="verificationCode:missingVerificationCode" minOccurs="1" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="infoVerificationCodeType"> <simpleContent> <extension base="token"> <attribute name="type" type="token" use="required"/> <attribute name="date" type="dateTime" use="required"/> </extension> </simpleContent> </complexType> <complexType name="codesType"> Gould Expires October 19, 2017 [Page 31] Internet-Draft verificationCode April 2017 <sequence> <element name="code" type="verificationCode:infoVerificationCodeType" minOccurs="1" maxOccurs="unbounded"/> </sequence> </complexType> </schema> END 5. IANA Considerations 5.1. XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Registration request for the verificationCode namespace: URI: ietf:params:xml:ns:verificationCode-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the verificationCode XML schema: URI: ietf:params:xml:ns:verificationCode-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See the "Formal Syntax" section of this document. 5.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: "Verification Code Extension for the Extensible Provisioning Protocol (EPP)" Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, <iesg@ietf.org> TLDs: Any Gould Expires October 19, 2017 [Page 32] Internet-Draft verificationCode April 2017 IPR Disclosure: None Status: Active Notes: None 6. Security Considerations The mapping extension described in this document is based on the security services described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. XML Signature [W3C.CR-xmldsig-core2-20120124] is used in this extension to verify that the Verification Code originated from a trusted Verification Service Provider (VSP) and that it wasn't tampered with in transit from the VSP to the client to the server. To support multiple VSP keys, the VSP certificate chain MUST be included in the <X509Certificate> elements of the Signed Code (Section 2.1.1) and MUST chain up and be verified by the server against a set of trusted certificates. It is RECOMMENDED that signed codes do not include white-spaces between the XML elements in order to mitigate risks of invalidating the digital signature when transferring of signed codes between applications takes place. Use of XML canonicalization SHOULD be used when generating the signed code. SHA256/RSA-SHA256 SHOULD be used for digesting and signing. The size of the RSA key SHOULD be at least 2048 bits. 7. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>. Gould Expires October 19, 2017 [Page 33] Internet-Draft verificationCode April 2017 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <http://www.rfc-editor.org/info/rfc5730>. [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <http://www.rfc-editor.org/info/rfc5731>. [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, <http://www.rfc-editor.org/info/rfc5732>. [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, <http://www.rfc-editor.org/info/rfc5733>. [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, <http://www.rfc-editor.org/info/rfc7451>. [W3C.CR-xmldsig-core2-20120124] Cantor, S., Roessler, T., Eastlake, D., Yiu, K., Reagle, J., Solo, D., Datta, P., and F. Hirsch, "XML Signature Syntax and Processing Version 2.0", World Wide Web Consortium CR CR-xmldsig-core2-20120124, January 2012, <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. Appendix A. Acknowledgements Appendix B. Change History B.1. Change from 00 to 01 1. Fixed pendingComplaince and complaint to pendingCompliance and compliant in text. 2. Fixed verificaton to verification. B.2. Change from 01 to 02 1. Added support for the notApplicable status value. Gould Expires October 19, 2017 [Page 34] Internet-Draft verificationCode April 2017 B.3. Change from 02 to 03 1. Added regular expression pattern for the format of the verification code token value in the XML schema. B.4. Change from 03 to 04 1. Ping update. B.5. Change from 04 to REGEXT 00 1. Changed to regext working group draft by changing draft-gould- eppext-verificationcode to draft-ietf-regext-verificationcode. B.6. Change from REGEXT 00 to REGEXT 01 1. Ping update. Author's Address James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisign.com Gould Expires October 19, 2017 [Page 35]