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

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

Girish,

That wording works for me, and it states the point better than mine:
reaching the source is not the same as completing the lookup.

If Dan and Adrian take the two requirements into -02, I'd use it as the
closing sentence of the second one, after the list of outcomes.

Francesco Marinoni Moretto
Independent

On Sat, Oct 10, 2026 09:21 AM, Girish Konda <[e-mail]> wrote:

> Hey Francesco,
>
> I agree on reporting the outcome and keeping the alignment separate from
> the field names. I'd carry your absence/incomplete distinction into the
> second requirement as:
>
> A finding that the referenced record is absent MUST be based on a complete
> result for the requested lookup. An incomplete result MUST NOT be reported
> as absence.
>
>
> Reaching the source isn't enough if the lookup didn't complete. That keeps
> the three outcomes distinct without making an absence claim from partial
> evidence.
>
> Thanks,
> Girish
>
>
> On Thu, Oct 8, 2026 at 1:39 AM Francesco Marinoni Moretto <
> [e-mail]> wrote:
>
>> 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]
>>>>
>>>