How it works in AgenID
The verifier fetches both, requires them to agree, then checks role and controller. A disagreement is key_discovery_mismatch, a hard fail. The well-known URI convention makes the second location predictable. Both copies must also match the operator key document carried in the resolution envelope, so a verifier is comparing three views of one key.
- Registry path:
GET https://www.agenid.com/v1/keys/<key-ulid>returns the key document. This is deployed. - Operator path:
https://<operator_domain>/.well-known/agenid/keys.json, one document listing every key the operator controls, published by the operator over HTTPS.
Why it matters
The operator path ties a key to a domain the operator controls, independently of AgenID. Domain evidence reports whether an operator's file strictly parses for that domain. The partner integration patterns show where a relying platform would run the check; each is a pattern, not a package.
It also keeps part of the verification path outside AgenID entirely: the operator's web server, its TLS certificate and its DNS are infrastructure AgenID does not run.
What it does not mean
If the operator publishes no copy, the verifier has one source, not two, and the key-substitution defense is not in force. Formal domain verification at L2 needs a VerificationAssertion signed by a root authority key, which has not been created, so the deployment issues nothing above L1_REGISTERED. A matching key identifies the signer; it says nothing about what the agent is allowed to do.