I have already started to lay out why we are going after the .secure TLD, let’s start the discussion of how it would be different.

As I have repeated to a dozen reporters in the last 36 hours, there are three legs to the .secure tripod, Verify, Secure and Enforce.  Although we are able to mandate the security controls and protocols be put in place by servers under .secure with today’s technology, we do not have the ability to communicate this escalated level of protection to the browser.  Doing so is a critical component of providing the effortless end-to-end secure experience that I believe users deserve.

To that end we are working on chartering the Domain Policy Working Group.  We cannot announce the initial slate of members while legal work is still occurring, but I do appreciate the support that others have voiced for the project.

I have attached our very very very early draft below.  This document was meant to explore the opportunities provided to us by a protocol like DPF, and there is a lot of work to be done before it is ready for the IETF.  In the meantime, feel free to leave comments here to send them to alex at artemis.net.  If you are really inspired to help, then let us know at info at domainpolicy.org and we’ll let you know when membership slots open.

Please keep in mind that this protocol is meant to be usable on any TLD, and in fact part of Artemis’ business will be to host DPF and other security services on behalf of security-sensitive TLDs.  This protocol should also be usable by the incumbent TLDs, so it’s important to design something that can scale to .com size while not negatively affecting sites that do not opt-in to DPF services.