The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Before its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfillment system.
EPP is based on XML - a structured, text-based format. The underlying network transport is not fixed, although the only currently specified method is over TCP. The protocol has been designed with the flexibility to allow it to use other transports such as BEEP, SMTP, SOAP or HTTPS. The individual submission documents were adopted by the IETF Provisioning Registry (provreg) working group, which was created after a BoF session was held at IETF-49 in December 2000. Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004. Draft Standard documents (RFCs 4930 - 4934) were published in May 2007.
In August 2009, IETF granted EPP the status of full standard as STD 69.
The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004.
ICANN has made it a condition in their base registry contract to offer an EPP service. Therefore, every gTLD has adopted the protocol.
There are multiple open source implementations of EPP server software. The Council of Country Code Administrators (CoCCA) maintains an EPP server software used by around 59 ccTLDs and six gTLDs. Another open source software is FRED (maintained by CZ.NIC) which counts 11 ccTLDs as its users.
Protocol commands
There are three classes of commands: Session management, query, and object transform. These commands can then be mapped onto objects, which specifies their exact functionality. contacts and domains. There are also other standardized objects like organizations, however they are rarely used.
When the client connects to a server, the server immediately sends a "greeting" message to the client. This message contains information about the server that the client needs to connect to. This contains the name of the server, the server's current date and time in UTC, the supported features, and a privacy policy. The supported features include EPP versions, languages, objects, and extensions. IDN, premium domain names, domain restoration (RGP) and extensions to handle the launch of new TLDs and Registry Maintenances among other things.
Some registries also developed extensions that are specific to their TLDs. A common use case for non-standardized extensions is collecting extra data needed to create a domain, for example, a VAT identification number.
Many domain name registries also offer to set up a IP whitelist for connecting to their EPP servers.
EPP offers some protection against replay attacks via the client generated <code>clTRID</code>, however this element is optional and is therefore not used by every server software. Therefore, additional anti-replay mechanisms should be implemented by the used transport mechanism.