DRPF Use Case

Administrative Control

Many (most?) large companies with subsidiary brand/marketing/product domains operate a single primary domain that represents the administrative corporate parent. When a relying party encounters a domain, it may be interested in learning what domain acts as their administrative parent. Even absent a more detailed policy document, confirmation of the relationship itself is of significant value.

This use case presents one of the simplest, versatile, and highly useful relationship signals between domains. This is a great use case to start with as it addresses the most common types of administrative relationships. Included are how to declare the administrative "parent" domains, its control over delegated "child" domains, as well as its relationship between "sibling / child / subsidiary" domains.

Illustration of Administrative Domain Relationships

Setting the Stage

Consider an application that aggregates a curated set of links related to a user's interests. Many of these links may reference domains that aren't apparently related, but there exists an underlying relationship. Examples include independent podcasts produced by a large network, single-purpose websites for books and movies on behalf of their production or distribution companies, or individual brand domains focused on specific products of a conglomerate.

In a security context, consider an application that comes across a domain and wants to understand as much about that domain as it can. Perhaps it's a URL-scanning browser extension that won't render the link without confirming administrative control over the domain.

Knowing the administrative root domain is also vital to understanding domains owned by a company and operated by a vendor. Consider that a company contracts a 3rd party to provide services across multiple domains operated by the vendor. Both the company and the vendor have a vested interest in clearly identifying all of the authorized domains being registered on behalf of the company.

In all of these cases, when the relying party encounters a domain (whether it's never been seen before, or previous information about the domain has aged out), it looks for a domain policy assertion record. In it, the domain can identify its administrative parent domain, enabling the relying party to retrieve the full domain policy document from the parent. The parent policy confirms the relationship, and can publis additional useful information about the domain and its purpose.

Simple Parent ↔ Child Declarations

The minimum steps required for a "child domain" to declare it's administrative "parent domain", and for the parent to confirm the relationship would be for the domain administrator (i.e. whoever has access to add DNS TXT RRs to each domain) to publish bi-directionally confimative statements. There are essentially two methods by which this can be accomplished: Domain Inference, and direct Policy Reference.

Domain Inference Method

In this simple method, the Child Domain operated as a subsidiary publishes an Assertion Record declaring nothing more than the Parent Domain as the administrative parent. The Relying Party then pings the Parent Domain for its Policy Document which is then retrieved and parsed to confirm the relationship. Depending upon the depth of the embedded Policy Documents (e.g. in which Child Domains are declared in linked policies), this may incur additional retrieval steps. While potentially incurring additional DNS lookups and HTTPS retrievals/parsing, it enables the Child Domain to publish nothing more than the Parent Domain. This is useful when the related Policy Document is unknown or changes frequently.

By way of example using this method, the subsidiary Child Domain (child.domain) may publish an Assertion Record that looks something as simple as:

"domrel;childOf:parent.domain;type:subsidiary;"

The Parent Domain might then publish something like:

domrel;apex:parent.domain;policy:https://parent.domain/relationships.json

Without going into too much detail about the structure, syntax, and semantics of the Policy Document, the JSON-LD snippet below illustrates the minimal information necessary to confirm the asserted relationship:

{
  "@context": [
    "https://schema.org",
    {
      "url": { "@type": "@id" },
      "domainRel": "https://domainrelationships.org/",
      "domainRel:relationType": { "@type": "@id" }
    }
  ],
  "@type": "Organization",
  "legalName": "Parent Company LLC Inc.",
  "domainRel:adminDomain": "parent.domain",
  "url": "https://www.parent.domain",
  "domainRel:isApex": true,
  "domainRel:hasChildRelation": [
    {
      "@type": "domainRel:ChildRelation",
      "domainRel:childDomain": "child.domain",
      "domainRel:relationType": "domainRel:Subsidiary"
    }
  ]
}

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 relationship declaration confirming that "child.domain" is, in fact, a subsidiary child of the Parent Domain. Of course additional related domains can be declared, and this simple example only illustrates the one relationship. More detail about domain policies, their semantics, syntax, and uses will be discussed elsewhere.

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

Sequence Diagram of Parent-Child Relationship - Inference Method

Policy Reference Method

This more direct method includes, in addition to declaring the Parent Domain, the Child Domain publishing an Assertion Record identifying the URL for the relevant Policy Document published by the Parent Domain. In this case, the Relying Party retrieves and parses the relevant Policy Document without having to first query the Parent Domain for the relevant Policy Document. While adding slightly more administrative burden to the Child Domain (i.e. requiring that the Assertion Record be updated if/when the relevant Policy Document location moves), it decreases the discovery burden of the Relying Party.

Using this method, the Child Domain publishes an Assertion Record that also includes a direct link to the relevant Policy Document such as:

"domrel;childOf:parent.domain;policy=https://parent.domain/relationships.json;type=subsidiary;"

The retrieved Policy Doument is identical to and would look the same as the one illustrated above. This method just simplifies the path to identifying and retrieving the relevant relationship policy with the discovery exchange simplified to something like:

The Relying Party may also perform a comparison between the declared domains and where the policies are retrieved as further signal confirming the relationship. If the referenced Policy Document(s) are hosted by different domains, it may be useful for the evaluating Relying Party to build (and cache according to the stated expiration directive) a relationship graph. But that's more sophisticated than is likely to be immediately useful and is left to be discussed in more detail elsewhere.