From: <hello@1euroseo.com>
To: <web-bot-auth@ietf.org>
Message-ID: <000a01dcf4b3$0c606700$25213500$@1euroseo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01DCF4C3.CFEBCF10"
Thread-Index: Adz0sgsLT5y5hYk0T8GxD8vmqIfHYA==
Content-Language: en-ie
Date: Fri,  5 Jun 2026 06:17:54 +0000 (UTC)
Message-ID-Hash: EUJ6ANC6524GGW73U7UBE7QLIYZJHL7P
Precedence: list
Subject: =?utf-8?q?=5BWeb-bot-auth=5D_Proposal=3A_Domain_Root_Identity_Anchor_for_Ori?=
	=?utf-8?q?gin/Publisher_Metadata_Discovery?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/web-bot-auth/u5Ae0T0owgAo2HBPSnZSGQpiMMM>

This is a multipart message in MIME format.

------=_NextPart_000_000B_01DCF4C3.CFEBCF10
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello WebBotAuth WG,

I would like to bring a proposal to the group for discussion regarding a =
standardized mechanism for conveying Origin/Publisher identity and =
metadata to automated clients using an existing, widely used identifier: =
the domain root.

Today, automated clients (including crawlers, AI agents, and retrieval =
systems) lack a deterministic, machine=E2=80=91readable way to discover =
the canonical identity of the Origin/Publisher behind a domain. Existing =
mechanisms such as robots.txt and llms.txt provide policy and =
content=E2=80=91level signals, but they do not establish a verifiable =
identity reference that bots can rely on for provenance, trust, or =
Origin/Publisher information.

The mechanism I am proposing defines a domain=E2=80=91root =
=E2=80=9CIdentity Anchor=E2=80=9D =E2=80=94 a machine=E2=80=91readable =
JSON/JSON=E2=80=91LD document discoverable via predictable endpoints and =
referenced from existing well=E2=80=91known files. This Anchor provides =
Origin/Publisher identity, organizational metadata, and optional =
cryptographic material, forming a stable identity layer that automated =
clients can use when interacting with a site. It also acts as a =
deterministic root=E2=80=91of=E2=80=91trust reference for verifying the =
provenance of site=E2=80=91level policies.

Key points:

=E2=80=A2 The Anchor is a discovery mechanism in v1, but its structure =
allows inclusion of a public key or link to a verifiable credential in =
future revisions.
=E2=80=A2 The mechanism is unidirectional in v1 (site =E2=86=92 bot), =
but is designed to support a bidirectional authentication loop where =
bots can bind their requests to the Origin/Publisher identity they have =
discovered.
=E2=80=A2 The Anchor can be complemented by an HTTP response header =
(e.g., =E2=80=9CBot=E2=80=91Operator=E2=80=91Identity=E2=80=9D or =
=E2=80=9COrigin=E2=80=91Identity=E2=80=91Anchor=E2=80=9D) for =
environments where header=E2=80=91level signaling is preferred.

Reference implementation:
https://1euroseo.com/llms.txt=20
https://1euroseo.com/identity.jsonld

Draft specification (WICG Issue #295):
https://github.com/marin-popov/semantic-anchor

I believe this aligns with the WG deliverable to define mechanisms for =
conveying additional information about a requesting bot using =
domain=E2=80=91based identifiers, and I would appreciate feedback from =
the group on whether this work is appropriate for further discussion or =
development within WebBotAuth.

Best regards,
Marin


------=_NextPart_000_000B_01DCF4C3.CFEBCF10
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:12.0pt;
	font-family:"Calibri",sans-serif;
	mso-ligatures:standardcontextual;
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-IE =
link=3D"#0563C1" vlink=3D"#954F72" style=3D'word-wrap:break-word'><div =
class=3DWordSection1><p class=3DMsoNormal>Hello WebBotAuth =
WG,<o:p></o:p></p><p class=3DMsoNormal>I would like to bring a proposal =
to the group for discussion regarding a standardized mechanism for =
conveying Origin/Publisher identity and metadata to automated clients =
using an existing, widely used identifier: the domain =
root.<o:p></o:p></p><p class=3DMsoNormal>Today, automated clients =
(including crawlers, AI agents, and retrieval systems) lack a =
deterministic, machine=E2=80=91readable way to discover the canonical =
identity of the Origin/Publisher behind a domain. Existing mechanisms =
such as robots.txt and llms.txt provide policy and content=E2=80=91level =
signals, but they do not establish a verifiable identity reference that =
bots can rely on for provenance, trust, or Origin/Publisher =
information.<o:p></o:p></p><p class=3DMsoNormal>The mechanism I am =
proposing defines a domain=E2=80=91root =E2=80=9CIdentity =
Anchor=E2=80=9D =E2=80=94 a machine=E2=80=91readable =
JSON/JSON=E2=80=91LD document discoverable via predictable endpoints and =
referenced from existing well=E2=80=91known files. This Anchor provides =
Origin/Publisher identity, organizational metadata, and optional =
cryptographic material, forming a stable identity layer that automated =
clients can use when interacting with a site. It also acts as a =
deterministic <b>root=E2=80=91of=E2=80=91trust reference</b> for =
verifying the provenance of site=E2=80=91level =
policies.<o:p></o:p></p><p class=3DMsoNormal><b>Key =
points:</b><o:p></o:p></p><p class=3DMsoNormal>=E2=80=A2 The Anchor is a =
discovery mechanism in v1, but its structure allows inclusion of a =
public key or link to a verifiable credential in future =
revisions.<br>=E2=80=A2 The mechanism is unidirectional in v1 (site =
=E2=86=92 bot), but is designed to support a bidirectional =
authentication loop where bots can bind their requests to the =
Origin/Publisher identity they have discovered.<br>=E2=80=A2 The Anchor =
can be complemented by an HTTP response header (e.g., =
=E2=80=9CBot=E2=80=91Operator=E2=80=91Identity=E2=80=9D or =
=E2=80=9COrigin=E2=80=91Identity=E2=80=91Anchor=E2=80=9D) for =
environments where header=E2=80=91level signaling is =
preferred.<o:p></o:p></p><p class=3DMsoNormal>Reference =
implementation:<br><a =
href=3D"https://1euroseo.com/llms.txt">https://1euroseo.com/llms.txt</a> =
<br><a =
href=3D"https://1euroseo.com/identity.jsonld">https://1euroseo.com/identi=
ty.jsonld</a><o:p></o:p></p><p class=3DMsoNormal>Draft specification =
(WICG Issue #295):<br><a =
href=3D"https://github.com/marin-popov/semantic-anchor">https://github.co=
m/marin-popov/semantic-anchor</a><o:p></o:p></p><p class=3DMsoNormal>I =
believe this aligns with the WG deliverable to define mechanisms for =
conveying additional information about a requesting bot using =
domain=E2=80=91based identifiers, and I would appreciate feedback from =
the group on whether this work is appropriate for further discussion or =
development within WebBotAuth.<o:p></o:p></p><p class=3DMsoNormal>Best =
regards,<br>Marin<o:p></o:p></p></div></body></html>
------=_NextPart_000_000B_01DCF4C3.CFEBCF10--