[Dawn] Re: [External] DAWN Coordination: Discovery Information and Trust Artifact Pointers

[Francesco Marinoni Moretto <[e-mail]>]

Girish,

Agreed on the third case. A reference that resolves but finds no record is
a different finding from one that does not resolve and from one that local
policy blocked, and the requirement should not only specify the behaviour
but also have the discovering entity report which of the three it hit.

The closed set is what makes that testable, and AID v2 shows it can ship.

If Dan and Adrian want the two requirements for -02, I'd write the second
one with the outcomes listed, and point to
draft-gilda-wimse-agent-audit-record for alignment rather than import its
vocabulary while it is still moving.

The same split appears in the AUDIT expected-record work: an absence
finding only holds when the source was fully observed; otherwise the result
is incomplete.

Discovery, evaluation and audit would all gain from not collapsing those.

Francesco Marinoni Moretto
Independent

On Wed, Oct 07, 2026 09:51 PM, Girish Konda <[e-mail]> wrote:

> Hey Folks,
>
> A couple of comments on the by-reference requirements, both on the
> unresolved case.
>
>    1. *Three Causes, One Reported Outcome:* Francesco’s second
>    requirement separates a reference that doesn’t resolve from one the
>    discovering entity’s own retrieval policy blocked. There’s a third, where
>    the reference resolves and the record is absent. All three end as no
>    discovery result, and they have different owners and different retries. A
>    requirement that specifies only behaviour still lets a discovering entity
>    report them identically, and that’s the state every later consumer inherits.
>
>    I have an Internet-Draft in AgentProto on the same distinction,
>    draft-konda-agentproto-evaluation-state-00
>    <https://datatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state/>.
>    Section 3 is the two-value problem and Section 4.2 is the cross-domain case
>    where a profile is identified but not held. The surface is discovery rather
>    than authorization and the shape doesn’t change.
>    2. *A Closed Set on Both Sides:* Balazs’s AID v2 carries a small fixed
>    set of failure outcomes, which is what makes the distinction checkable
>    rather than advisory. draft-gilda-wimse-agent-audit-record is closing the
>    same kind of set on the verifier side right now.
>
> We should align the two vocabularies while both are still open, or a
> discovery failure and an evaluation failure end up recorded in terms that
> can’t be compared.
>
> Thanks,
> Girish
>
>
>
> On Tue, Sep 29, 2026 at 12:14 AM Francesco Marinoni Moretto <
> [e-mail]> wrote:
>
>> Balázs, Dan, Enrique,
>>
>> Thanks, Balázs, that is useful twice over. It narrows what the
>> by-reference change was meant to do: a single pointer to a capability
>> description for REQ-PROP-9, not chains.
>> And AID v2 shows the second option can be met in practice: one hop, no
>> redirects during verification, a fixed set of failure outcomes.
>> That answers the obvious worry that a depth limit is easy to write and
>> hard to ship.
>>
>> On Enrique's question, your point and the two requirements fit together.
>> The minimum verification material stays by value, anything richer sits
>> behind a reference, and that reference is then covered by the depth limit
>> and the failure behaviour.
>> The minimum never depends on a fetch the client may not be allowed to
>> make, and everything behind it has defined behaviour when that fetch fails.
>>
>> Dan, Adrian, with -01 expiring on 30 October: if the second option works
>> for you, Balázs has offered to help with text and I'm glad to draft it with
>> him for -02, and you place and number it as you see fit.
>>
>> Francesco Marinoni Moretto
>> Independent
>>
>> On Fri, Sep 25, 2026 01:40 PM, Balazs Nemethi <[e-mail]>
>> wrote:
>>
>>> Hi Francesco, Dan, Enrique,
>>>
>>> When I raised the by-reference point back in April it was only about
>>> REQ-PROP-9. Read strictly, that requirement could force capability data
>>> into the discovery record itself. I wanted a single pointer to the
>>> capability description (an agent card, an MCP manifest or something) to
>>> count as well. Chains were not in scope, and "usability" was not my
>>> wording. So I'd back Francesco's second option: a depth limit, defined
>>> behaviour when a reference cannot be resolved, and defined behaviour when
>>> the client is not allowed to fetch it.
>>>
>>> One data point. Our AID v2 shipped in June. On these questions it landed
>>> at one hop: the record points at the endpoint, no parent-name walking, no
>>> chained lookups. No redirects followed during verification; a cross-origin
>>> redirect after discovery needs policy or user approval. A small fixed set
>>> of failure outcomes, so "unresolvable" has defined behaviour. The result
>>> also says whether it came from DNS or the HTTPS fallback, so local policy
>>> can decide what to accept.
>>>
>>> None of that is DNS-specific. DNS has a role because the domain owner
>>> already controls it, but another mechanism could meet the same requirements.
>>>
>>> On Enrique's question: I'd keep the minimum verification material by
>>> value. We carry a public key in the record. The endpoint proves possession
>>> on the first request the client makes anyway, and in v2 it can also confirm
>>> it serves the domain that pointed to it. Richer trust material can sit
>>> behind the endpoint. A minimum that depends on a fetch the client may not
>>> be allowed to make is fragile.
>>>
>>> Happy to help with text.
>>>
>>> Balázs
>>>
>>> On Fri, Sep 25, 2026 02:53 PM, Francesco Marinoni Moretto <
>>> [e-mail]> wrote:
>>>
>>>> Dan, Enrique,
>>>>
>>>> Picking up Dan's offer to record following a reference as an open
>>>> question:
>>>> I think the requirements draft already has the spot where it gets
>>>> answered,
>>>> and right now that spot is empty.
>>>>
>>>> Section 1.1 of draft-king-dawn-requirements-01 allows the indirection
>>>> outright:
>>>>
>>>>      "A discovery mechanism may return such information directly or
>>>>      provide a reference to another resource from which the information
>>>>      can be obtained, provided that the requirements for authenticity,
>>>>      integrity, interoperability, and usability are satisfied."
>>>>
>>>> Three of those four conditions have requirements behind them.
>>>> Authenticity and integrity are REQ-SEC-1. Interoperability is carried
>>>> by REQ-PROTO-4. Usability has none: the word occurs exactly once in
>>>> the whole document, in the sentence above, and no requirement in
>>>> Section 3 names it.
>>>>
>>>> The clause is load-bearing. "Either directly or by reference" appears
>>>> in REQ-PROP-2, REQ-PROP-3, REQ-PROP-8, REQ-PROP-9 and
>>>> REQ-PROP-12, so four MUST-level requirements and one SHOULD
>>>> can be satisfied by a reference, and all five inherit a condition the
>>>> document does not define.
>>>>
>>>> Dan, your point about layering is the reason this matters rather than
>>>> an objection to it. If following the reference is an application
>>>> exchange, then it sits outside discovery, and the usability condition
>>>> in 1.1 rests on a step the document does not specify. As drafted it
>>>> cannot be checked: there is no way to tell whether a discovery
>>>> mechanism satisfies it.
>>>>
>>>> Two ways out, and the authors and the list should pick, not me.
>>>> Either define usability as a term, which would mean Section 2 and
>>>> draft-farrel-dawn-terminology, where the other terms come from, or
>>>> drop the word from 1.1 and replace it with requirements that can be
>>>> verified. If the second, this is the substance I would suggest, with
>>>> the numbering and the placement left to you:
>>>>
>>>>      A discovery mechanism MUST specify the maximum depth of indirection
>>>>      a discovering entity is required to follow, and the behaviour when
>>>>      that depth is exceeded.
>>>>
>>>>      A discovery mechanism MUST specify the behaviour of a discovering
>>>>      entity when a reference obtained through discovery does not
>>>> resolve,
>>>>      including the case where the discovering entity's own retrieval
>>>>      policy, rather than the network or the server, prevents resolution.
>>>>
>>>> The last clause of the second is the part I would not drop.
>>>> Retrieval policy is now a real constraint and not a hypothetical one.
>>>>
>>>> OpenAI documented in January 2026 that an agent checks "whether that
>>>> URL matches a URL previously observed by the independent index", and
>>>> that when it does not match, "we treat it as unverified and do not
>>>> trust it immediately". A conformant reference, correctly published and
>>>> reachable on the network, is still not followed automatically if no
>>>> independent index has seen it. A discovering entity that behaves this
>>>> way is acting reasonably, and the requirements draft currently says
>>>> nothing about what it should do instead.
>>>>
>>>> Enrique asked whether the minimum discovery information includes a
>>>> pointer to a later-stage trust artifact set, or whether locating those
>>>> artifacts is the consumer's problem. That is a closely related
>>>> question: whichever way it lands, the condition attached to every
>>>> reference the document already allows still needs a definition or a
>>>> replacement.
>>>>
>>>> On credit, the -01 announcement says the revision was mostly "to
>>>> address comments and suggestions from Jim Mozley and Balazs Nemethi",
>>>> with by-reference as its main change, and Section 8 acknowledges both
>>>> of them for the discussions that shaped the document. The gap in
>>>> "usability" is my reading, and not something either of them raised.
>>>>
>>>> Happy to write either the definition or the two requirements as text,
>>>> whichever the authors prefer.
>>>>
>>>> Francesco Marinoni Moretto
>>>> Independent
>>>>
>>>>
>>>> Il 10/09/2026 12:31, King, Daniel ha scritto:
>>>> >
>>>> > Hi Enrique,
>>>> >
>>>> > Thanks for this! I only just noticed the email when I was scanning
>>>> the
>>>> > list. Agree that it’s more likely question(s) to put to the
>>>> > Architecture work rather than to the use cases.
>>>> >
>>>> > For what it's worth, the 01 use cases draft (just posted) already
>>>> > assumes discovery can provide an earlier reference, and treats
>>>> > following it as an application exchange. Does it belong in the
>>>> minimum
>>>> > info, no strong opinion (especially from a use case perspective),
>>>> > happy to record it as an open question though.
>>>> >
>>>> > One aspect we did underline, is in the minimum set then it's
>>>> discovery
>>>> > information (to start the relationship), then authenticity, integrity
>>>> > and visibility, et al. is layered afterwards, depending on the
>>>> > intent/task.
>>>> >
>>>> > I will look at draft-somoza-dmsc-atn-agent-trust-negotiation and
>>>> > comment accordingly.
>>>> >
>>>> > BR, Dan.
>>>> >
>>>> > *From:*Enrique Somoza <[e-mail]>
>>>> > *Sent:* 07 September 2026 16:17
>>>> > *To:* [e-mail]
>>>> > *Subject:* [External] [Dawn] DAWN Coordination: Discovery Information
>>>> > and Trust Artifact Pointers
>>>> >
>>>> > *This email originated outside the University. Check before clicking
>>>> > links or attachments.*
>>>> >
>>>> > Hi all,
>>>> >
>>>> > Not a charter comment... I'm aware external review closed on 31
>>>> > August. This is a coordination note for whenever the WG gets going,
>>>> > since the charter has a coordination section and the boundary I want
>>>> > to raise is one DAWN has already drawn itself.
>>>> >
>>>> > draft-kay-dawn-use-cases puts it well: discovery is not a statement
>>>> > that the discovered entity is safe, competent, or authorised, and it
>>>> > supplies discovery information and trust indicators while policy and
>>>> > selection are later functions. The proposed charter is consistent
>>>> with
>>>> > that, holding identity management and trust evaluation methods out of
>>>> > scope for the initial phase.
>>>> >
>>>> > I think that boundary is right. My suggestion is only that the
>>>> > Architecture document be explicit about where it falls. When the WG
>>>> > specifies the minimum discovery information, there is a question of
>>>> > whether that minimum includes a pointer to a later-stage trust
>>>> > artifact set, or whether locating those artifacts is entirely the
>>>> > consumer's problem. Either answer works. Leaving it unstated is what
>>>> > costs, because a consumer that has to fetch policy artifacts out of
>>>> > band ends up round-tripping twice for what could have been one
>>>> > indirection, and adding the pointer later is a format change.
>>>> >
>>>> > I have a stake in the answer, so declaring it: I author
>>>> > draft-somoza-dmsc-atn-agent-trust-negotiation, which specifies the
>>>> > later-function side — capability, delegation, provenance, and a
>>>> signed
>>>> > receipt of what two parties agreed. It is deliberately
>>>> > discovery-agnostic and takes a discovered, authenticated identity as
>>>> > input, so it does not need anything from DAWN. But it is one of the
>>>> > consumers that would use such a pointer if it existed, which is why
>>>> > I'd rather the question be answered on purpose than by default.
>>>> >
>>>> > Happy to review the Architecture or Use Cases documents from the
>>>> > consuming side if that is useful.
>>>> >
>>>> > Enrique Somoza
>>>> >
>>>> > Independent
>>>> >
>>>>
>>>> --
>>>> Questa email è stata esaminata alla ricerca di virus dal software
>>>> antivirus Avast.
>>>> www.avast.com
>>>> _______________________________________________
>>>> Dawn mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>> Dawn mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>