One Article Review
| Source |  ProofPoint |
|---|---|
| Identifiant | 8446027 |
| Date de publication | 2024-02-02 05:00:36 (vue: 2024-02-02 16:08:34) |
| Titre | Développement d'une nouvelle norme Internet: le cadre de la politique relationnelle du domaine Developing a New Internet Standard: the Domain Relationship Policy Framework |
| Texte | Engineering Insights is an ongoing blog series that gives a behind-the-scenes look into the technical challenges, lessons and advances that help our customers protect people and defend data every day. Each post is a firsthand account by one of our engineers about the process that led up to a Proofpoint innovation. In this blog post, we discuss the Domain Relationship Policy Framework (DRPF)-an effort that has been years in the making at Proofpoint. The DRPF is a simple method that is used to identify verifiably authorized relationships between arbitrary domains. We create a flexible way to publish policies. These policies can also describe complex domain relationships. The details for this new model require in-depth community discussions. These conversations will help us collectively steer the DRPF toward becoming a fully interoperable standard. We are now in the early proposal stage for the DRPF, and we are starting to engage more with the broader community. This post provides a glimpse down the road leading to standardization for the DRPF. Why Proofpoint developed DRPF To shine a light on why Proofpoint was inspired to develop the DRPF in the first place, let\'s consider the thinking of the initial designers of the Domain Name System (DNS). They assumed that subdomains would inherit the administrative control of their parent domains. And by extension, this should apply to all subsequent subdomains down the line. At the time, this was reasonable to assume. Most early domains and their subdomains operated in much the same way. For example, “university.edu” directly operated and controlled the administrative policies for subdomains such as “lab.university.edu” which flowed down to “project.lab.university.edu.” Since the mid-1980s, when DNS was widely deployed, there has been a growing trend of delegating subdomains to third parties. This reflects a breakdown of the hierarchical model of cascading policies. To see how this works, imagine that a business uses “company.com” as a domain. That business might delegate “marketing.company.com” to a third-party marketing agency. The subdomain must inherit some policies, while the subdomain administrator may apply other policies that don\'t apply to the parent domain. Notably, there is no mechanism yet for a domain to declare a relationship with another seemingly independent domain. Consider a parent company that operates multiple distinct brands. The company with a single set of policies may want them applied not only to “company.com” (and all of its subdomains). It may also want them applied to its brand domains “brand.com” and “anotherbrand.com.” It gets even more complex when any of the brand domains delegate various subdomains to other third parties. So, say some of them are delegated to marketing or API support. Each will potentially be governed by a mix of administrative policies. In this context, “policies” refers to published guidance that is used when these subdomains interact with the domain. Policies might be for information only. Or they might provide details that are required to use services that the domain operates. Most policies will be static (or appear so to the retrieving parties). But it is possible to imagine that they could contain directives akin to smart contracts in distributed ledgers. 3 Design characteristics that define DRPF The goal of the DRPF is to make deployment and adoption easier while making it flexible for future use cases. In many prior proposals, complex requirements bogged down efforts to get rid of administrative boundaries between and across disparate domains. Our work should be immediately useful with minimal effort and be able to support a wide array of ever-expanding use cases. In its simplest form, three design characteristics define the DRPF: A domain administrator publishes a policy assertion record for the domain so that a relying party can discover and retrieve it. The discovered policy assertion directs the relying party to where they can find |
| Envoyé | Oui |
| Condensat | 1980s 500 ability able about abuse accompanying according account acronym across actions adams adding additional address addresses administrative administrator adoption advances adviser after agency akin all allows already also amiss analog analytics analyze another answer any api appear application applications applied applies apply approach arbitrary arc architecture are array aside assertion assume assumed astronaut authenticity authorization authorized author avoids awakens backgrounds based because becoming been before behind best better between beyond bidirectional blend blog boards bogged both boundaries bowl brand brands breadth breakdown bring broader build built business but can cancer career careers cascading case cases cases chain challenges change characteristics chief child:status:parked;” clear cloud collaborate collaborates collaborations collectively com com; come commerce common communicate community companies company complex complexity compliance com” confirm confirmation confirmed confirming consider considering constantly contain context contracts control controlled conversation conversations conveys corporate correlated cosmic could create cross csp customer customers data day declaration: declare deep defend define defined defines definitions delegate delegated delegating dependencies deployed deployment depth describe design designers detail details develop developed developers developing development digital directed directive directives directly directs discover discoverable discovered discuss discussions disparate distinct distributed diverse diversity dmarc dns dnssec document documentation domain domains don down driven driving drpf drpf: drpf dynamic each early earned easier easily easy ecosystem edu edu” effectively effort efforts emerge enables encouraging enforced engage engineering engineers england enhance esoteric especially essentially evaluate even ever every evolve evolving example excited exciting executive exist expanding expectation expectations experience experiences expirations exploration extended extending extension fact feature features fido film find first firsthand flexibility flexible flowed focused follow force form found foundation framework from full fully further future futurist get gets getting gives glimpse goal goes governed growing guidance happen has have heads help helped heretofore hierarchical hire his how identify identity imagine immediately impossible include includes including independent indicates information inherit initial innovation innovator insight insights inspired instance instead intelligence intent interact interacting interaction interactions interest interested internet interoperability interoperable intricate introduces is: isoc issue its itself join joining keep key know knowledgeable lab later layers leading learning led ledgers lessons let light like like: likely line lived location long look lot make makes making management manager many marketing masks maximum may meaning meanwhile mechanism mechanisms media method mid might minimal mix model models modern modify more most much multiple must name ncorp nearing nearly necessary need needed needs new next not notably note: now oauth offer one ongoing online only openid operated operates operations opportunities organizations other otherwise overview page parent parks parse parties party passion patriots paving payment people perform perspective place platform please point pointers points policies policies policy possible post potential potentially powerful practical primary primitives prior privacy process processors producer proofpoint proposal proposals protect protecting proven provide provider provides providing provision publication publish published publishes purported question questions rarely ready real realized reasonable record refers reflects registers regulatory related relationship relationships rely relying reporting require required requirement requirements research resounding retrieve retrieves retrieving reveal rid rings ris |
| Tags | Tool Prediction Cloud Technical |
| Stories | |
| Notes | ★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.