Policy Assertion Record
The first step is to publish something that tells the world that a policy exists. Given that the policies relate to relationships between domains, it makes sense to publish it as a simple text (TXT) resource record (RR) within DNS. For lack of a better term, we can think of this as a "policy assertion record." Meaning, it's just asserting a few simple policy statements, while directing relying parties where more complex policy statements can be found.
There are several benefits to not baking all possible domain policy statements into DNS, especially with simple DNS RRs limited to 255 characters. More importantly, the policies may become arbitrarily complex as use cases emerge and are adopted. Similarly, policies may be highly dynamic such that different policies may be returned based upon the relying party. Various policies and use cases are discussed later, but for now, it's worth focusing on the minimum amount of information a policy assertion record must contain.
In this model, at a minimum, the policy assertion record would contain a URL (or even just a domain) where the relying party can retrieve the full policy record. We'll discuss the information and usage of policies in more depth later. But in some cases, the policy being communicated may be simple enough to bake right into the assertion record itself.
Example: The policy assertion record may declare that the domain is "parked", or otherwise not in use for any reason. As such, there may be no need to retrieve any other policy. Once a "not in use" policy assertion record is published, that may be the end of it.
Another simple element included in the policy assertion record would be a field that indicates the domain is subordinate to another "parent" domain. Following the previous example, it may be useful for the "parked" domain to indicate the entity that registered and purposefully sidelined it. This is of particular interest when a well-known company registers a lookalike domain that can be used to impersonate one of its brands.
So, in a minimal configuration, a policy assertion record may be all that's needed in some contexts. For example, a domain may publish an assertion that the domain is "inactive," and identifies its "parent" domain. That tells relying parties a lot about the domain without having to publish a full policy document. In this case, when a relying party checks the "parent" domain for bi-directional confirmation of the relationship (which we discuss later), they will discover the relevant policy document.
Example: Consider what may happen when delegating a subdomain for use by a 3rd party. There are various ways
that this can be accomplished, each of which will require considerations for where to publish one or more policy assertion record(s).
The first case to consider is when the domain administrator delegates the subdomain using an A record pointing to an IP address operated
by the 3rd party. In this case, the policy assertion record can be published as a simple TXT RR for that subdomain as it will be retrieved
with a simple query. Doing so, however, does not allow the 3rd party to publish their own policies for the subdomain.
If, however, the subdomain is delegated using a CNAME, both the original domain administrator as the delegator and the 3rd party delegee can publish
their own policies. In this case, the original domain administrator could publish their assertion as a TXT RR within an attribute leaf label
(as per RFC 8552), while the 3rd party could publish their policy assertion as
a TXT RR at the domain targeted by the CNAME declaration.
Bi-Directional Confirmation
Once a policy assertion record is found, the relying party follows the URL to retrieve the associated policy document. Next, the relying party needs to confirm the relationship between the assertion and the policy.
To do so, the policy document declares the existence of the subordinate domain that published the discovered assertion policy. This can be as simple as a list in the policy document that identifies the domains over which the policy has authority. The list could be broken into various classifications by type, but we'll leave that for future discussion.
Importantly, this bi-directional confirmation prevents a rogue domain from publishing a policy assertion indicating a relationship that doesn't exist. It also enables a domain to sever a relationship at any time, signaling to relying parties that a previous relationship no longer exists.
Example: Consider that a relying party discovers the policy assertion record from "inactive.com". The record declares its parent to be "active.com", and the relying party retrieves the policy document from the associated URL. After parsing the "active.com" policy document, the relying party finds that "inactive.com" is listed as a "parked" domain, confirming the relationship.
In a slightly more complex example, consider that "marketing.company.com" is operated by a 3rd party marketing company. To clarify the relationship, a relying party discovers the policy assertion record at "marketing.company.com" and retrieves the policy document from "company.com." Within the policy, the relying party finds that "company.com" declares that "marketing.company.com" is operated by "marketing.com", and the subdomain is authorized to send email. Later we will discuss additional opportunities for declaring policies related to the third party (e.g. requiring pinned certificates for various uses).
This example also begins to introduce the concept of chained policies. Given that "company.com" confirmed that "marketing.company.com" is operated by "marketing.com", the relying party may decide to seek a policy assertion document from "marketing.com", too. That policy document may, in turn, confirm the relationship that it operates "marketing.company.com" on behalf of "company.com", thus closing the loop.
While we've only discussed simple relationships so far, it is likely that a more comprehensive set of semantics will be required. It's unlikely that the number of defined relationship types will be very large, and well adopted ontologies will be useful when specifying those that are useful in this context.
Domain Policy Documents
The policy document is where a domain publishes detailed information about the relationships between domains and associated usage policies for them. The proposed model is highly extensible and conceptually builds upon the namespace concepts defined by structured data standardized by the W3C.
In general terms, the model leverages existing ontologies (e.g. Schema.org), and includes only those primitive data structures necessary in supporting most use cases. The policy document can also reference special-purpose syntax definitions as needed. This approach allows the model to be useful to most simple use cases while allowing for extension that requires specific subject matter expertise.
Don't Panic: It can be hard to conceptualize how powerful a simple policy can be, especially given how complex all of this looks. But we need a lot of words to paint a picture for how much more the power of simplicity can be amplified through extension. So, if you're averse to verbose descriptions... feel free to skip ahead to the use cases section that illustrates the flexibility of the model by way of examples.
Policy Document Structure
Each policy document is broken into two basic structures: a header, and one or more policies. The header contains a set of metadata that provides information about the domain and its general uses. The detailed information and instructions are included in the policies section.
The metadata in the header alone may include enough information to address most use cases. For example, a relying party may only be interested in declarative statements about the domain (e.g. contact information for the company that operates the domain). As such, there may be use cases that don't depend upon the policies at all.
- Header Metadata: A data structure containing general information about the domain, its operator, and declared uses.
- Policies: One or more structured policies that include the following:
- Vocabularies: Declarations that identify the syntax and ontology used within the policy.
- Data Structures: The data necessary to define the policy within the given vocabulary.
- References: Links to additional policies that, when taken in combination, define the full set of policies.
Policy Primitives
The core of a policy includes a limited vocabulary that defines only a few primitives beyond those referenced from existing ontologies. These are elevated to primitives as they are useful for a vast majority of policies. More specific vocabularies are included by reference from other ontologies as necessary.
- Metadata: The basic set of information necessary to describe the core policy for a domain. This includes company name, logo associated with the domain, basic contact information, and timestamps (e.g. publication dates and expiration directives).
- Domain Usage: A constrained set of classification types for expected domain usage. They're intended to quickly convey basic usage guidance to relying parties. For example, "active", "parked", "defensive", etc.
- Relationship Labels: A term for the general vocabulary used to define common relationships between domains. For example, "parentof:", "childof:", "operatorof", "operatedby", "onbehalfof:", "governedby:", "supplierto:", "customerof:", etc.
- Certificates & Signatures: In the absence of DNSSEC, the relying party may want to verify that the policies are legitimate and authorized. As such, there is a method for publishing certificates and policy signatures.
Policy Chaining
Given the dynamic nature of domains, their uses, and relationships, their policies will constantly be evolving. Similarly, not all policies for a domain (or set of domains) are governed by the same organization (or even the same department within an organization). As such, policies must enable the inclusion of other policies (and you can see that means yet more included policies, all the way down).
A set of primitives are defined to support multilevel chained policies:
- URL: Direct link to specific policies via URL that should be included in the aggregate set of policies. This method is useful when including policies from various domains.
- Domain: Inclusion of policies published via a specific domain. This method would be useful in the context of subordinate domains with no specific policy requirements beyond those of the "parent" domain.
- Restrictions: Given the nature of arbitrary inclusion of policies that may change over time, the policy may provide guidance regarding how to handle potential policy collisions (e.g. a domain in one jurisdiction my include the policies of other jurisdictions, and require a mechanism to indicate which jurisdiction takes precedence). The policies may also indicate content-level restrictions or exclusions (e.g. the domain may publish content under the copyright of the company, while the copyright of user-generated content may be held by the individual author).
Extensible Policy Model
To avoid baking all potential use cases into a single policy vocabulary, the DRPF supports a highly extensible semantic model that can grow as needed. The semantics defining those policies relies upon other proven models. The underlying protocol focuses on the publication, discovery, and parsing of generic policies. The key to extensibility is the ability to publish policies of arbitrary complexity so the relying party can effectively identify and parse those that matter to them.
In this case, the most relevant model that has proven to work is the Resource Description Framework (RDF) defined by the World Wide Web Consortium (W3C). The concept is that the industry agrees on a publication and retrieval mechanism for standardized ontologies (known or yet to be defined). It is then up to the relying party to identify and parse those ontologies it recognizes (while ignoring those that it does not).
To parse the ontology in the published policy, it must be serialized in a standardized format. The initial version of RDF used by the semantic web relied on XML formatting. Given that XML has fallen out of favor, though, it may be worthwhile to leverage the version of JSON used in the JSON-LD linked-data format. While it doesn't really matter how the identified vocabularies are represented, it's useful to adopt a serialization format in common use. The important aspect is that there's a mechanism to identify the ontology and serialization method in use and apply the appropriate parsing engines.
Slight Digression: Do you immediately cringe when hearing the term "Semantic Ontology?" I totally understand your reluctance to wade into the murky waters of the semantic web. After all, what good has come of that particular foray? Actually, quite a lot. While the "move fast and break things" Internet has largely ignored the power of machine-readable ontologies, many industries have found incredible value in the linked-data models TBL and others pioneered. A powerful recent, hightly relevant example is the rapid research and development of the COVID-19 vaccines. The biomedical field embraced semantic modeling nearly 20 years ago when they began encoding research papers so they could be parsed by reasoning engines to identity viable treatment candidates. Without that work, pharmaceutical companies would not have been able to develop vaccines as quickly as they did over the past couple of years. So... yes. Semantic models are intimidating. But ignoring them for that reason is no reason at all.
Deployment Burden
With this architecture, the burden for processing rests primarily with the relying party. The domain administrator is only required to publish a policy assertion record within DNS which covers many simple use cases. Optionally, they may also opt to publish one or more detailed policy documents to provide additional information for more complex use cases. The relying party is then responsible for processing the assertion statements and policy documents.
This architecture can be contrasted with an API model where the relying party makes specific method calls to the host which then responds with the information requested. The architecture proposed in this document assumes that more domain administrators are likely to begin publishing useful information if they don't need to deploy a full API endpoint with all that entails. This should more quickly unlock early value in the solution while supporting long term growth.
One further note is that the architecture does not rule out a future API extension. It is possible to add an API endpoint declaration in the policy assertion record, announcing that relying parties can retrieve the desired information via predefined method calls. This could be further enhanced with the introduction of authorization tokens to control which relying parties can retrieve what information. Until such time where use cases and demand call for it, however, this enhancement should be left for future consideration.
