Subsidiary / Brand / Cousin Domains
Companies often operate a variety of domains serving various purposes (e.g. as a subsidiary, promoting an individual product brand, or serving a
specific purpose) which can make it difficult for a relying party to identify with any certainty that there's a relationship between a subsidiary
or brand domain and their coporate administrative domain. There are, however, innumerable benefits to knowing when a domain is legitimately associated
with a larger corporate organization.
Example: Consider that the primary corporate domain for General Mills is "generalmills.com", while many (though not all) of its
breakfast cereal brands operates its own domain (e.g. "kixcereal.com", "cheerios.com"). Sharing a single corporate administration, the domains operate
individual websites that typically link to common legal statements (e.g. terms of service, privacy policies, etc.) hosted at the corporate domain.
In other cases, subsidiaries or product-specific domains are registered only to direct to other domains or directly to pages hosted by the corporate domain.
There are a number of ways a domain administrator can redirect some or all traffic to corporate sites (e.g. by serving a "HTTP/1.1 301 Moved Permanently"
directive for web traffic), leaving the relying party to guess at the reasons for the relationship.
Example: Consider the medical device manufacturer Themo Fisher Scientific that operates the corporate domain "thermofisher.com".
The product domains "invitrogen.com" and "dionex.com" redirect web traffic to deep links within the "www.thermofisher.com" website rather than
operating independent websites for each brand... or perhaps the domains were part of an aquisition and a previous website at the domain was decommissioned.
In any case, without explicit information about the relationships and uses of the domains, relying parties are left to make their own inferences. It would
be a lot more effective, accurate, and efficient if the domains explicitly published useful information that relying parties could... well... rely on.
Another vexing problem is when a company registers domains not as subsidiaries or in service to product brands, but for specific purposes across a single
product line. These secondary domains are often termed "cousin domains" as they're related (in some undefined way) to a primary domain.
Example: Consider the primary user-facing customer domain for The Kroger Company (the parent of a handful of grocery stores) is "kroger.com",
while "thekrogerco.com" acts as their corporate home, they delegate "krogerfeedback.com" to handle receipt surveys, and "krogersc.com" to operate their
pharmacy accounts. Unfortunately, there is no way for a relying party to know with any certainty that they are legitimate domains related to The Kroger Company
(and not malicious lookalike domains).
And we don't want you to think that we're only focused on domains used for websites. In fact, many of these related domains include MX records directing
email to their delegated mail server, while others publish no MX record at all. And while some do, many do not, publish an SPF record indicating the domain
may be used to send email from the authorized IPs on behalf of the domain (or explicitly announcing that the domain never sends email). Even within a single
company's portfolio of related domains, its common to find domains that are spun up for one purpose (e.g. web) while not intended for another (e.g. email)...
and it'd be useful for the domain administrator to announce their use to relying parties.
Declaring Domain Relationships
There are innumerable ways that domains can be related, though there are only a handful of top-level differences that most relying parties may find of use
in making decisions when interacting with them. To support both the most common use cases as well as providing extensibility for domain administrators
to provide detailed relationship information, the DRPF enables simple declarations within the assertion record, as well as more detailed relationships
being defined within linked policy documents.
Simple Subordinate Domain Declaration
To support simple subordinate domain relationships, the subordinate domain can publish an Assertion Record declaring their relationship in terms of
a dominant parent domain. The relationship would be one of a small set of defined declarations such as "childOf, "subsidiaryOf", or "brandOf" along with the
related dominant domain. This type of Assertion Record, absent a direct link to a more detailed Policy Document indicates to a relying party that
the subordinate domain is clearly under the administrative control of the dominant domain, and that the relying party can discovery / retrieve / parse
the full set of DRFP policies from the dominant domain.
By way of example, a subordinate child domain that services a product brand (brand.domain) may publish a DNS TXT RR Assertion Record that looks something
as simple as:
"domrel;brandOf:parent.domain;"
The relying party, upon discovering this Assertion Record, could then query the dominant parent domain "parent.domain" for its own Assertion Record
in order to retrieve / parse / and confirm the relationship. While the referenced parent domain might explicitly declare the relationshiup in
their own Assertion Record, it's more likely (and useful), for the "parent.domain" to include a link in their Assertion Record to a more detailed
DRFP Policy Document such as::
"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 useful
information to confirm the relationship asserted by "brand.domain":
{
"@context": [
"https://domainrelationships.org/",
{
"schema": "https://schema.org/",
"gr": "http://purl.org/goodrelations/v1#"
}
],
"@type": "schema:Organization",
"schema:legalName": "Parent Company LLC Inc.",
"isApex": true,
"schema:url": "https://www.parent.domain",
"hasChildRelation": [
{
"@type": "gr:brand",
"relation": "isChild",
"adminDomain": "parent.domain",
"domain": "brand.domain",
"gr:name": "Product Brand Name",
"gr:description": "Product Brand Name is a product of Parent Company LLC Inc.",
"status": "active"
}
]
}
In the above snippet you'll see that it relies on the default "domainrelationships.org" ontology and references both the "Schema.org"
and "Good Relations"
ontologies. And while the snippet is slightly contrived (e.g. we could replace the Good Relations propoerties with equivelant ones from Schema.org), but it's worth
illustrating the use of multiple ontologies within a single Policy Document.
The ability to reference various fine-tuned ontologies unlocks nearly infinite extensibility. Just about any
relationship can be defined either using the default DRPF ontology, or one that's specific to the applicable industry. For example,
FIBO is an ontology specifically tuned to support the financial industry.
Regardless of the specific relationship being described, the following swimlane diagram illustrates the basic discovery exchange:
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;status=active;"
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.
