Re: Proposal: AI Domain Data Standard for Authoritative Domain Identity Metadata

Thank you Sunray, this is well thought out feedback, and I am glad you address them early.
First, the contact details and the feeling of reintroducing the WHOIS privacy risk. You’re right that “publishing contact” can regress toward the old WHOIS dynamic if interpreted as put your personal admin email here. That is not the intent, and I should make this clearer in this group.
In AIDD v0.1.x, the contact field is intentionally defined as “email or URL”. The preferred pattern is a role contact or a controlled entrypoint, e.g. :

  *   https://example.com/contact (or a dedicated support/help URL)
  *   mailto:support@example.com / mailto:hello@example.com (not personal addresses)

So the goal is: an official escalation surface, not deanonymizing an admin identity.
That said, your point is valid: even role inboxes can attract phishing or pressure. Two mitigations I think are appropriate and consistent with the current design principles:

  *   Update guidance in official documentation: recommend contact be a URL (contact form/help page/etc.), or have dedicated email for this field, and
  *   Security guidance: explicitly call out that AIDD is public metadata and should avoid personal addresses; pair with standard practices (rate limiting, forms, aliases, DMARC/DKIM/SPF, etc.).

On “should this be WHOIS instead”: I see why that’s appealing, but practically WHOIS is:

  *   not consistently accessible post-GDPR,
  *   not designed as an AI-consumable identity surface, and
  *   entangles a lot of registrar/ICANN policy and privacy concerns

AIDD’s aim is narrower: a domain-controlled, web-native declaration using mechanisms domains already use (/.well-known/ + optional DNS), without re-opening the WHOIS privacy debate.

Next is taxonomy/semantic fragmentation. I agree with the core concern: if identity classification becomes “everyone invents their own labels,” you get noise.
AIDD is deliberately minimal in v0.1.x for this reason. Today it only has one optional “taxonomy-ish” field: entity_type, and the spec guidance is that it SHOULD use schema.org @type values directly (Organization, Person, Project, etc.). That’s meant to avoid a new bespoke taxonomy.
For the human-facing description, I view it as a summary string like:

<meta name="description">

rather than a taxonomy primitive. It’s not intended for automated classification beyond simple display, and consumers shouldn’t treat it as a controlled vocabulary.
Your suggestion (OID-like identifiers) is interesting for a future extension, especially if AIDD ever grows beyond identity into richer assertions (topics/products/services). If that happens, I’d strongly agree that we should not invent new label spaces; we’d want something like:

  *   references to established vocabularies (schema.org, Wikidata QIDs, NAICS/industry codes, etc.), and/or
  *   a registry/namespace mechanism for identifiers that is stable and unambiguous.

But I’m cautious about introducing that complexity into the core identity profile, because it increases implementation burden and creates governance questions.

My bias is this: keep v0.1.x focused on “who are you / where is your official presence,” and treat any “what you do / what you offer” taxonomy work as a versioned, opt-in extension once there’s clear demand.

Agreed in principle: any machine-consumable surface can be abused. Two points here:

  *   The v0.1.x schema is intentionally constrained (fixed keys, no additional properties) to keep parsing predictable.
  *   Resolvers should treat the record as publisher-asserted identity, not as a trust override. It’s an anchor signal, not a reputation system.

If the group thinks it’s useful, I can add a short “Security & Privacy Considerations” section that:


  *   recommends contact URLs by default,
  *   discourages personal identifiers, and
  *   states clearly how consumers should treat the data (assist identity resolution, not bypass trust/ranking).

Again, thank you. This is exactly the kind of feedback that helps avoid unforced errors early.
Best regards,
Dylan Larson


________________________________
From: Sunray Zak <sunrayzak@icloud.com>
Sent: Sunday, December 28, 2025 8:30 PM
To: Hans Petter Blindheim <hans.petter.blindheim@gmail.com>
Cc: Edward <edward.in.01101@gmail.com>; dylan larson <dylanl37@hotmail.com>; Warren Parad <wparad@rhosys.ch>; Daniel Vinci <me@danielvinci.com>; Jason Grigsby <jason@cloudfour.com>; g b <bgauryy@gmail.com>; public-wicg@w3.org <public-wicg@w3.org>
Subject: Re: Proposal: AI Domain Data Standard for Authoritative Domain Identity Metadata

Dear Community,
To me, the idea of exposing Domain Contact details seems to go back to era when those were unmasked in the WHOIS database.
Perhaps WHOIS could have been extended and re-opened it that is the actual issue targeted?
This would give back the privacy gains achieved and open those admins again for phishing and other potential attacks (perhaps even political pressure).

Regarding other domain attributes, yes I support that for structured exposure but as a data architect I see the issue of taxonomy here - instead of TEXT types describing labels, those should be references to an open model (in the style of SNMP OIDs if you will) to the actual LABELS applicable to the domain site content.
Otherwise there will be lots of noise and discrepancies / semantic fragmentation in those “freeform” self-given descriptions.
Perhaps even parsing exploits ;)

Regards
Sunray