Jacques, Very interesting brain teaser. I concur with Jody that for performing the verification in the registration, the pending create model via the 1001 response to the domain create can be used to perform the server-side verification if it cannot be done immediately along with the pending action poll message. The verification detail could be included as an extension to the pending action poll message if a simple boolean is not enough.
For the pre-verification, I see multiple options: 1. Create an extension of the domain object mapping, like what you have defined in draft-latour-pre-registration. You would need to create new EPP verbs. As stated by Jody, use an extension of the check command, either an extension of the availability check, as demonstrated by the Registry Fee Extension in RFC 8748, or the definition of a new verification check verb, as demonstrated by the claims check in the Launch Phase Extension in RFC 8334. I get the feeling that the verification is more unique and better suited for a separate verb. Anything beyond creating a new check verb will run into complexities. 2. Create a separate verification object mapping with the full suite of commands (check to do a quick verification, create to start a longer verification, update to change a pending verification, info to get the state of the verification and to receive a verification token, poll message of info response sent by the server). The China Name Verification Mapping in draft-ietf-regext-nv-mapping is an example of defining a verification object mapping. In the case of the China Name Verification Mapping, a successful verification resulted in the generation of the digitally signed verification code that complies with the Verification Code Extension in draft-ietf-regext-verificationcode. The concept of the use a digitally signed verification code works well if a 3rd party is performing the verification function, which doesn’t sound like the case that you’re looking to do. If the same party is performing the verification that later receives proof via a generated token, you may not have the need for digital signing. You could leverage the Allocation Token Extension in RFC 8495 to contain the verification token that could authorize the registration. Based on the experience that I’ve had with verification; my recommendation is to go down option #2 so that you can specifically define the interface that is needed for pre-verification without the complexity of having to define new verbs. There are many options related to providing the results of the verification in the registration, if that is what is needed, such as the use of a token that is passed in the Allocation Token Extension, or a digitally signed typed code that is passed in the Verification Code Extension, or caching the verification in the registry based on the domain name without the need to pass anything, or creating a custom extension of the Domain Object Mapping to pass the generated verification information. Thank you for sharing, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Jody Kolker <jkolker=40godaddy....@dmarc.ietf.org> Date: Thursday, November 16, 2023 at 3:24 PM To: Jacques Latour <Jacques.Latour=40cira...@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org> Cc: Don Slaunwhite <don.slaunwh...@cira.ca>, "t...@internetnz.net.nz" <t...@internetnz.net.nz> Subject: [EXTERNAL] Re: [regext] I-D draft-latour-pre-registration Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Jacques, A couple of observations: 1. Would it be possible to allow the registry to determine if the verification can be done instantly or needs to be delayed. If it is instantly, return a 1000 with the results, if it can’t return 1001. If the verification can be done instantly a verification command is not needed. 2. If 1001 is returned from the command, I would imagine the registry would through the information on a queue to be reviewed, and once reviewed, the registry could send a poll back to the registrar, thereby eliminating the need for a verification command and allowing the registry to perform deeper analysis if needed. I can imagine that this process will not be in the purchase path for a domain, but will happen after the domain is purchased, but not registered. Waiting for a poll message might be perforable. 3. From a purely semantic point of view, should this extension be sent with the check command instead of the create command? The object is not created but is being verified, more of a check (even though the objects may be temporarily created). Thanks, Jody Kolker 319-329-9805 (mobile) Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com<mailto:scourt...@godaddy.com>) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: regext <regext-boun...@ietf.org> On Behalf Of Jacques Latour Sent: Wednesday, November 15, 2023 9:57 AM To: regext@ietf.org Cc: Don Slaunwhite <don.slaunwh...@cira.ca>; t...@internetnz.net.nz Subject: [regext] I-D draft-latour-pre-registration Some people who received this message don't often get email from jacques.latour=40cira...@dmarc.ietf.org<mailto:jacques.latour=40cira...@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Hi all, At the ICANN78 meeting and other venues, there were quite a lot of discussion on AI/ML abuse detection related discussions and presentations. * Example: https://static.sched.com/hosted_files/icann78/de/4%20%2020231023-TechDay-AI%20at%20EURid.pdf<https://secure-web.cisco.com/12rIPwEOtGUvSjI4Bm4omHESSzfohjoDZXoWK_SJ0JceMVnIHvXUA4uOxNLHClainv3lR8Iu1lg3R9IjJbCDqqgbkk6bxoJuW-WEYEqrJLRklkZGR-Ct-hZXS6ktKA09pg7yVtmDKvfa0SobiOeP_I6Mz8uun1YtEPX91jX7BRI-d0kcwx2YUNxg58ZYUPNa3yMlk00rur63csO_DlZTsnjDhtC_XYX-9orqVi-X1xfM2Aha26SYTQDmXSc-n98QTh_FVWltL3NxErFuGP69L9WMfIV925CW0qAJA-rEPRw4/https%3A%2F%2Fstatic.sched.com%2Fhosted_files%2Ficann78%2Fde%2F4%2520%252020231023-TechDay-AI%2520at%2520EURid.pdf> But this is after the fact, after a registration is completed, so we thought of a new extension to allow the registrar to ask the registry that have this real time capabilities to analyse the pre-registration information and return a quality score to better inform the process. draft-latour-pre-registration-00 - EPP Pre-Registration Verification (ietf.org)<https://secure-web.cisco.com/1_jZTM-EIfQE0A9btVogGNAmEWA6-k_ocgUj27qEQJSEFT4g3e9V1khb3itUP9_Atcoc9bAt0jXyiErP-KM2wxhMIBuer4P76mU8LG45fUrSoG45Yt2A1wgu3IL2JOXVH0zi5qq86QWull-Dz6KljwA70I4jY0g2andFWMRpYzp3Z9VPVlJxKI5A6T77jLl9sTOOIrK-2uEj9wcR6x1j27jExaaFAS0Ylty2r63_dVBZf145elouIlY84GdmFWvijV2dmcpOWawZZiTrx5jQG3OvlXmF0bYKfEgixewavw08/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-latour-pre-registration%2F> Have a read, Jack CLASSIFICATION:CONFIDENTIAL
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
