DRPF Overview

The Domain Relationship Policy Framework (DRPF) is a simple method for identifying verifiably authorized relationships between arbitrary domains, including an extensible mechanism for publishing policies that can also describe complex domain relationships. This effort has evolved over the past decade, with the details for this new model requiring in-depth community discussions to collectively steer it toward a fully interoperable standard. Were in the early proposal stage as we begin to engage with the broader community more fully, and this post is an early glimpse ahead down the road leading to standardization.

Motivating Problem Statement

The initial designers of the Domain Name System (DNS) assumed that subdomains would inherit the administrative control of their parent domains. The same considerations should be applied to all its subdomains. This was a reasonable assumption at the time given that most early domains and their subdomains were typically operated by the same entities. For example, university.edu directly operated and controlled the administrative policies for subdomains such as lab.university.edu which continued flowing down to project.lab.university.edu.

Since it was widely deployed in the mid 1980s there has been an accelerating increase in subdomain delegation to 3rd parties, breaking down the hierarchical model of cascading policies. For example, consider a company that operates company.com, and they delegate marketing.company.com to a 3rd party marketing agency. There are some policies that the subdomain must inherit while the subdomain administrator may apply other policies not applicable to the parent domain.

There is currently no mechanism for a domain to declare a relationship with another seemingly independent domain, in a separate branch, nor any way to declare related (or distinct) policies that apply. Various models have been proposed (more discussion on that later), but as of this writing, none of the proposals have stuck. This paper outlines the basic characteristics of a potential solution and proposes a technical mechanism that (with minimal effort) meets the goals (with room for significant expansion as needed).

Domain Relationships & Why They Matter

Many organizations leverage multiple domains, including subdomains and other related domains, for various uses. And while a domain may have some measure of inferred administrative control over its subdomains, there is very little (if any) relationship that can be inferred between entirely distinct domains. For example, if two domains operated by a single entity are registered with different registrars (and perhaps obtained through an acquisition), there would be no way to programmatically identify a relationship between them, let alone that they should be covered by the same corporate policies.

Example: Consider a conglomerate, that uses "company.domain" as its corporate domain, registering a new domain, "brand.domain" to be used in conjunction with a new product they're planning to sell. The conglomerate may want to declare that they operate, and are applying their policies to, the new domain (e.g. acting as a parent to the new child domain). Doing so clarifies the relationship for any party that relies on knowledge about domain relationships (e.g. search engines) as the conglomerate prepares for the launch of the new product. Knowledge of the relationship may also enable the warming up of the new domain for use with email (e.g. by enabling receivers to jump-start its reputation based on that of the conglomerate).

Similarly, when considering reputation systems and threat analysis, the absence of reliable relationship information between domains can be interpreted as a negative signal. For example, a new domain that doesnt publish verifiable relationships with long-standing domains may be start with a lower reputation score than a domain verifiably related to a domain with an established reputation.

These examples focus primarily on the existence of verifiable, directional relationships between domains. And while knowledge of parent:child and extended sibling or cousin relationships between domains are inherently valuable in-and-of themselves, the Domain Relationship Policy Framework (DRPF) being proposed here extends well beyond these declarations to support highly extensible domain policies.

A Brief Introduction to Domain Policies

For the purpose of this discussion, the term domain policies (or just policies since the context of the discussion is already domains) refers to characteristics associated with the use of the domain, or guidance in the handling of information associated with the domain. Policies may simply be informational in nature, or provide specific details required to use services operated by the domain.

More detail on policies is discussed later, but here are a couple of example policies to help set the stage:

A standardized policy mechanism would simplify and vastly improve the ability of domain administrators to declare their control over domains. A single mechanism could replace the numerous ad-hoc token records in use today (while also providing the opportunity to include additional context).
Not all domains within a single hierarchy should be treated equally, and policies may indicate authoritative relationships between subdomains. For example, a subdomain may be operated by a 3rd party marketing agency and the policy clarifies that relationship.
Some policies may be used to declare specific configuration settings for an API end point operating on the domain that are required to be obeyed when connecting to it. For example, specific certificates and tokens may be required that can be retrieved by obeying declarations within the policy.

The specific mechanism for publishing and retrieving policies are left for discussion later. For now, assume that the policies are published such that they can be retrieved via RESTful HTTPS calls and represented in a common data structure like JSON-LD. The specific syntax and semantics will be left for later in the discussion.

Solution Design Characteristics

There are three design characteristics that define the solution being proposed:

Publish a policy assertion record for a given domain so that it can be discovered by a relying party.
The discovered policy assertion directs the relying party where the accompanying policy document can be found.
Beyond a set of simple policy primitives, the syntax and semantics to be used in the policy document is defined separately by those interested in specific use cases.

Essentially, this work focuses on defining a standardized way to publish policies that describe domain relationships, and a way that those policies can be discovered. Beyond that, the policies themselves are fully extensible and can be defined as use cases present themselves. This separation avoids the complexity of baking all possible policy models into one specification.

The only requirement is that the policy assertion be published in an easily discoverable location and point to where the policy document can be retrieved. This level of abstraction supports simple adoption (especially for simplistic use cases) while allowing for maximum flexibility (as necessary for supporting complicated or otherwise esoteric heretofore unknown use cases).

NOTE: This simplicity masks the powerful ability to support arbitrarily more complex use cases, so well start simple and show how it can be extended as needed.