SCHOOL CONTACT

Category: Identity & Security

  • Cybersecurity by Design: The Contact Initiative Approach

    The Contact Initiative treats cybersecurity as an infrastructure-level property, not an add-on, through a defined set of controls:

    • Verified, role-based identity for every user, separate from any reassignable number.
    • Zero-trust access to the resolution layer — no standing access for any relying party, vendor, or MI agent.
    • Non-enumerable, rate-limited query-response verification, preventing bulk scraping of the identity graph.
    • Mandatory DNSSEC, SPF, DKIM, and enforced DMARC on every issued domain.
    • Aliases that hide the administrative address, shrinking the target for spear-phishing.
    • Scoped, short-lived credentials for vendors and MI agents instead of raw record access.
    • Persistent, tamper-evident logging at both the institution and national-registry level.
    • Mandatory dual control for high-impact actions like bulk data export or identifier retirement overrides.
    • A public security-disclosure and bug-bounty commitment for the registry and its reference implementation.

    That vendor-focused control matters most: reported research indicates a majority of disclosed K–12 breaches trace back to a compromised vendor, not the district itself. Tokenized, scoped, short-lived vendor credentials are aimed squarely at closing that pathway.

  • Machine Intelligence and the Future of School Communication

    Consider a simple instruction given to an MI assistant: “Email my professor about the extension.” Without reliable identity infrastructure, the system has to guess which course, which professor, which section, and whether the requester is even enrolled — and it sometimes guesses wrong.

    Why “MI,” Not “AI”

    The Contact Initiative deliberately uses Machine Intelligence (MI) instead of Artificial Intelligence (AI) wherever reasonably possible, to describe capability that operates strictly within a human-governed structure — able to act only after a person or institution is verified, and only within limits a human governance body has set and can revoke at any time.

    How the Authorization Layer Works

    Before an MI assistant can act, it must request a scoped grant limited to the specific task at hand — never standing access to a person’s full academic or communication record. If a request is ambiguous, a human-approval threshold is triggered and the assistant asks for confirmation instead of guessing. Every credential is short-lived, and every action is logged for audit.

    This is also the foundation for the Machine Intelligence Assistant (MIA) — a proposed persistent, personalized tutoring and mentoring assistant for students and researchers, operating entirely within these same scoped, revocable, and auditable boundaries.

  • How Aliases Protect Students and Parents from Phishing

    Earlier drafts of the Contact Initiative imagined a public, browsable directory where anyone could look up a verified teacher or administrator. Review identified an obvious problem: a browsable list of every verified educator in the country is also a ready-made target list for harassment.

    Query-Response, Not Browsable

    Version 5 replaces the browsable directory with query-response verification. A relying party submits a specific claimed identity — “is this person currently a teacher at this school?” — and receives a confirm or deny answer, rate-limited to prevent bulk scraping. This preserves the entire anti-phishing benefit of the original idea while removing the enumeration risk.

    Aliases That Can Be Replaced Without Losing Identity

    Institution-issued aliases follow role-based, human-readable patterns and can be rotated or reissued at any time without affecting the underlying identity anchor or its attestation history. A compromised or leaked alias can simply be retired and replaced — no loss of identity continuity, and a much smaller practical target for spear-phishing.

    A Non-Negotiable Security Baseline

    Every domain issued under the Contact Initiative — production or sandbox — is proposed to carry DNSSEC and registry lock to prevent hijacking, enforced SPF, DKIM, and DMARC with a reject policy to stop spoofed mail from delivering as genuine, and a published, cryptographically signed list of real Contact Initiative domains so relying parties can spot look-alikes.

  • The Four-Layer Identity Model, Explained

    Earlier drafts of the Contact Initiative proposed a single, centrally issued national identifier — a ten-digit number assigned at enrollment and later released back into a national pool for reassignment. Technical and legal review flagged two serious risks: a reassigned identifier can carry forward old associations, and a single national identity store is one high-value breach target for an entire population’s personal data at once.

    Version 5 replaces that design with a federated, four-layer model that delivers the same fast lookup and clear tiering — without either risk.

    The Four Layers

    • Identity anchor — a locally issued, opaque identifier for each person, controlled by the state or district (K–12) or institution/federation (higher ed). Never reused — retired and archived instead.
    • Federation / attestation layer — short-lived, cryptographically signed claims (“this anchor currently maps to an enrolled student”) held by the national registry. No bulk personal data.
    • Alias layer — the human-facing address people actually use day to day, freely rotatable without touching the anchor beneath it.
    • Relationship / authorization layer — a mutable table of who currently holds guardianship or delegated authorization for a given anchor.

    This separation is what lets the system handle situations the old single-number model couldn’t: a custody change becomes an update to the relationship layer, not a reissued child identity; a name change updates the alias without disturbing the anchor; and one person — say, a parent who is also a graduate instructor — can hold multiple independently scoped attestations under a single anchor.

  • Why American Schools Need a Verified Identity Layer

    The United States runs the largest and most decentralized education system in the world — roughly 13,000 K–12 school districts and several thousand colleges and universities, each building its own communication and identity infrastructure independently, platform by platform. No shared layer of verified identity connects any of it.

    The result shows up in ordinary moments that should be simple. A parent can’t always confirm that a message claiming to be from their child’s teacher is genuine. A receiving school can’t instantly verify a displaced student’s enrollment history. A voice assistant or classroom MI tool has no authoritative way to resolve an instruction as basic as “email my teacher.”

    Not Just an Inconvenience

    This fragmentation is the underlying condition that makes phishing, impersonation, shadow IT, and slow emergency response possible at scale across American education. Reported industry research indicates that a large majority of K–12 schools have experienced a cybersecurity incident in recent years, and that most publicly disclosed K–12 breaches trace back to a compromised vendor rather than the district itself.

    Beneath the statistics sits a simple structural gap: no unified framework exists to verify the identity of a sender in K–12 communication. A phishing email can convincingly imitate a district’s branding. A caller can claim to be a parent with no way for office staff to check the claim. A bad actor can register a fake teacher-style address and message students directly.

    School Contact proposes treating identity — for students, parents, teachers, and administrators alike — as shared infrastructure: persistent, verifiable, and portable across every transition in a person’s path through the education system. Read the full architecture in our White Paper Overview.