DRPF Use Case

Vendor Registered Domains

Similar to sibling / cousin / subsidiary domains registered by a conglomerate, other domains may be registered by 3rd party vendors to provide services on behalf of the conglomerate. The primary difference is that the 3rd party vendor, and not their customer company, has administrative control over the domain (and, by extension, all subdomains). This difference may be due to the vendor operating dedicated infrastructure, or simply as an expedience (e.g. it was simply easier for the vendor to register and operate the domain). Regardless of the reason, the company and vendor must now collaborate when publishing appropriate policies to ensure relying parties recognize the authorized relationship between the domains.

Unleashed (Marketing) Domains

A common situation in marketing is when a company hires a 3rd party vendor to run a sales campaign of some sort. It's often faster / easier for the sales department to contract an outside vendor for the campaign than to go through the proper domain registration process set up by the company (if they even have one). And, frankly, sometimes they don't even know what the "right" process is, and just aren't thinking much about it. However the domain was registered, if it is going to be operated by the vendor according to the company's administrative policies, coordination will be required between the domain administrators of the company and vendor.

Example: Consider a vendor that registers "shoesoffer.domain" on behalf of their customer that primarily operates their business using the domain "shoes.domain". Even though it is the vendor that registered and officially administers "shoesoffer.domain", they may still be required to follow specific policies dictated by their customer, as published by "shoes.domain". In this case, the policies of both the customer company and the operating 3rd party vendor will need to be published and discoverable. Keeping in mind that the vendor may also publish their own policies at the newly registered domain, and/or at their corporate domain.

Clear from this example is that, absent a DRPF policy describing the relationship, there is no way for a relying party to know if the domain regisered by the 3rd party is authorized... or it's to be used as part of an impersonation attack. It is similar to a "cousin domain" registered by the company itself, but even another step removed which can make it that much harder to identify as legitimate. The introduction of bi-directionally confirmed DRPF policies can eliminate any doubt.

And as is obvious to most marketers whose success lives and dies based on open/click rates in delivered email, brand new domains registered for a campaign can can easily sink their numbers. New domains typically must go through a "warm up" process by which they're gradually introduced to mail flows so that receivers can build a reputational image for them before they're fully trusted. A verifiable DRPF policy clearly identifying the new domain as being operated according to administrative policies associated with an existing, trusted domain, can also help jump-start the warm-up process, clearly differentiating them from a domain with unknown provenance.

Declaring a Vender-Registered Domain

Unlike a simple company-registered domain, it's likely more effective to skip the inference method for determining the appropriate policies given that two different entities are involved. So, in this case, the vendor registered domain "child.domain" may publish an assertion record explicitly referencing a single domain: explicitly publish two parent policy documents something like:

domrel;policy:https://vendor.domain/relationships.json;

In that case, the referenced policy document will include decalarations defining the relationship such that the relying party can determine the customer and retrieve any other associated policies. This could indicate that the vendor is the primary administrative operator of the domain.

Another option would be for the assertion record to explicitly declare that there are two policies that apply by referencing both policy documents:

domrel;policy:https://vendor.domain/customers.json;policy:https://customer.domain/vendors.json;

In the above example, the assertion record explicitly links to two dedicated policy documents. One document hosted by the vendor declares their customer relationships, while the customer policy defines their vendor relationships. The referenced policy documents can, of course be as general or as specific as is useful in the context, deep linking additional policies as necessary to provide additional context.

Vendor Policy Document

Without going into too much detail about the structure, syntax, and semantics of the Policy Document, the JSON-LD snippet below illustrates information that can be used to define the asserted relationship between the registered "campaign.domain" domain, vendor as the administrative operator "vendor.com", and customer identified as "customer.domain":

{
  "@context": [
    "https://schema.org",
    {
      "url": { "@type": "@id" },
      "domainRel": "https://domainrelationships.org/",
      "domainRel:relationType": { "@type": "@id" }
    }
  ],
  "@type": "Organization",
  "legalName": "Vendor Operator LLC Inc.",
  "domainRel:adminDomain": "vendor.domain",
  "url": "https://www.vendor.domain",
  "domainRel:isApex": true,
  "domainRel:hasOnBehalfOfRelation": [
    {
      "@type": "domainRel:onBehalfOfRelation",
      "domainRel:childDomain": "campaign.domain",
      "domainRel:onBehalfOfDomain": "customer.domain",
      "domainRel:policyURL": "https://customer.domain/vendors.json",
      "domainRel:relationType": "domainRel:Active",
      "domainRel:relationReason": "domainRel:VendorOperated"
    }
  ]
}

You'll notice that the snippet references both "Schema.org" and "domainrelationships.org" schemas, and it should be clear a lot more useful information can be published in the Policy Document. For now, we'll focus on the declarations defining the relationships between "campaign.domain" as the child domain being operated by "vendor.domain" on behalf of "customer.dom". More detail about domain policies, their semantics, syntax, and uses will be discussed elsewhere.

Customer Policy Document

Given that "campaign.domain" is being operated on behalf of "customer.domain", the Relying Party will want to also retrieve their relevant Policy Document published at the referened URL:

{
  "@context": [
    "https://schema.org",
    {
      "url": { "@type": "@id" },
      "domainRel": "https://domainrelationships.org/",
      "domainRel:relationType": { "@type": "@id" }
    }
  ],
  "@type": "Organization",
  "legalName": "Customer Name LLC Inc.",
  "domainRel:adminDomain": "customer.domain",
  "url": "https://www.customer.domain",
  "domainRel:isApex": true,
  "domainRel:hasVendorRelation": [
    {
      "@type": "domainRel:VendorRelation",
      "domainRel:childDomain": "campaign.domain",
      "domainRel:vendorDomain": "vendor.domain",
      "domainRel:policyURL": "https://vendor.domain/customers.json",
      "domainRel:relationType": "domainRel:Active",
      "domainRel:relationReason": "domainRel:VendorOperated",
      "domainRel:relationExpires": "1739502488"
    }
  ]
}

When comparing the two snippets, you'll notice that the Policy Document published by the customer mirrors that of the vendor, confirming the relationship. An additional directive included in the customer policy is the explicit declaration when the relationship expires (as a UNIX timestamp). This example illustrates that the customer wants to declare the expiration, while either party could publish a similar directive. In this way, the policy administrators can effectively control when the relationship is over (e.g. useful when a domain and associated relationship is intended only to operate during the specified period of the campaign).

The swimlane diagram for the discovery exchange may then look something like:

Sequence Diagram of Vendor-Operated Relationship

Once all of the Policy Documents are retrieved and parsed, the Relying Party can identify the declared relationships, build (and cache) their own graph of the relationships between the domains. From there, they can make their own decisions about how to deal with the domains and apply reputation metrics as appropriate.