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

[Girish Konda <[e-mail]>]

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]
>