• Home
  • About
    • Kyle Den Hartog photo

      Kyle Den Hartog

      Hacker. Golfer. Futurist. Skier. Developer.

    • Learn More
    • Email
    • Twitter
    • LinkedIn
    • Github
    • StackOverflow
  • Thoughts
    • All Posts
  • Projects
  • Resume

Decentralizing Age Verification with SSI: Separating Content Moderation from Guardianship

18 Jul 2025

Reading time ~7 minutes

Today, we see that age verification laws are being passed, which enshrine the principle that we can perform age checks and protect people under a certain age through content moderation. However, we ultimately adopted this centralized content moderation solution due to the inherent architecture of the centralized trust model established by the digital credentials we rely on. That centralization led us down a path to coupling a generic content moderation problem and a guardianship problem as a means to an end of protecting children. The byproduct is that we are reducing the agency of everyone on the Web because servers need to, by default, assume users are not old enough unless they can prove they are with a third-party attested claim. There is a more private and decentralized way to solve these problems if we separate the content moderation problem and guardianship problem with separate answers to each.

To solve the content moderation problem, we rely on the assumption that content can be classified into buckets of safe and unsafe content on a granular level. This assumption has to hold whether it is done in a centralized way with age verification credentials (so the server can filter out the content before sending it) or an alternative way, such as with client-side filtering relying on lists like what we have with SafeBrowsing and Adblock lists, which are more private and decentralized alternatives to preform content moderation.

Today, these lists work by classifying content based on the origin and filtering the request in the browser. This heuristic has been good enough for the most part. However, with SafeBrowsing V5, Google Chrome is introducing the use of on-device real-time classification to detect sites that impact users’ security in real-time. The same model could theoretically be repeated with any content or served in an HTML page by adding classification tags to the HTML. Alternatively, the server could tag it directly in HTML, and then lists or configurations inform the browser how it should filter the page locally before rendering the content. So that is what makes content moderation more private because it happens only on the device. Furthermore, it becomes a more generally applicable approach to content moderation, which may be useful for blocking any form of content on the Web. For example, I configure my Twitter account to block all tweets that mention Elon Musk, but theoretically, with this system, I could apply it across the Web. I could also subscribe to a list maintained by a third party I trust who blocks all content related to topics I wish to self-moderate from. However, this system has to be opted out of at least in order to provide the agency principle.

Now, I’m sure many of you are already thinking that the children will just opt out, but that is where the guardianship problem comes into play. Today, the most effective forms of enforcement of these content filtering systems occur within schools via IT administrators applying device management policies or network-level blocking. So, if we extended these capabilities to configure the generic content filtering at the operating system level, then the browser or other applications on the device rely upon those features to make sure the content filtering happens on the children’s devices and doesn’t get bypassed. Additionally, if the browser is not able to determine that the content is safe, it could be configured by default to block the site and allow bypass approvals from an authorized guardian, such as the school IT administrator, a teacher, or a parent. Alternatively, it could be configured to allow access to the content but log it so the school lists could be updated.

Furthermore, since parents could utilize these same theoretical operating system guardianship features (or provide consent for the IT admins at their school to configure it through BYOD policies) such that these devices can’t bypass the system it becomes a more technologically appropriate solution that allows parents, teachers, and IT admins to fluidly enforce as it aligns with their morals when raising their child. For example, guardians may choose to allow access to sensitive books or block sites relevant to topics they deem unsuitable for their children, but other guardians may be all right with it. In this way, we don’t end up with centralized institutions for content platforms, the governments issuing the credentials, and the regulators determining which content needs to be filtered.

In this way, we decentralize the enforcement out to millions of school districts or well-informed parents acting as guardians who should understand these problems and are well-versed in the cat-and-mouse game of content filtering bypasses. Furthermore, digital credentials still come into use here, too, but we subtly shift the trust triangle to make it work.

For example, let’s say that a teacher has a managed device and wants to reference a specific blocked page, or a child wants access to a specific chat feature in a game at home for a limited period of time. Then the operating system would be configured to recognize and trust the teacher’s or parent’s DID, which could issue a digital credential authorizing permission to access the content. In this way, the browser (or other applications) and operating system work in tandem to act as the verifier, not the centralized site server. Furthermore, because there’s only a limited number of guardians who could issue these credentials, the system doesn’t need to fall back to a small number of centralized, known issuers or content classifications that enforce their moral discretion onto large populations of people. Instead, people would be able to selectively either self-moderate or defer moderation rights to a guardian, which, as Ada Palmer points out in the blog post I linked previously, is the most effective method of moderation today.

To understand how this might appear, from a user experience perspective, the child would attempt to access a piece of content like normal, and it would be blocked. The child’s browser (the verifier) would then request that the operating system (the holder) provide a valid credential. If it has one, it presents it; otherwise, the operating system reaches out to the parent’s or teacher’s device to get issued a new credential. A notification would pop up on the guardian’s device, where a clear prompt would identify what the credential is for, how long it’s used for, and maybe even whether it should be logged by the operating system so it can be sent back to the guardian for later review. Side note, this might be a circumstance where phone home is a feature rather than a bug to help parents monitor the content their children are accessing.

In this way, by subtly shifting who plays what role, we’ve reused the technology for the same purposes, but in a more decentralized way because the issuance is not bound to only a small select number of institutions, but it is still scalable. Furthermore, the solution is more private for everyone on the Web because sites are not required to collect personal data. However, they do still have a responsibility to tag content using the content tags that are required by regulators. Additionally, the user can configure their content moderation themselves or defer it to third parties of their choosing, like we do with Adblock lists, depending on how granular the classification problem becomes. In this way, we achieve a more private and secure solution that remains scalable, allows individuals or guardians to self-moderate as is best aligned with their moral discretion, and this is achieved because we opt for a decentralized architecture both in terms of credential issuance and in the sense of content moderation lists, where users opt in.

In summary, this is just one example of how the choices we make for the trust architecture have a profound impact on the solutions we end up with. It acts as a blueprint too for how we can think about different approaches for other use cases that balance tradeoffs by using decentralized trust as a means to an end, not a liability to be avoided. I hope this helps exemplify more meaningfully, too, for how we can leverage these technologies in an alternative way that leads to more equitable outcomes for all and remain aligned with our principles.



SSIWeb