MIME-Version: 1.0
References: 
 <IA3PR10MB87356B61E1C2A66D44458298ACB22@IA3PR10MB8735.namprd10.prod.outlook.com>
 <CWLP265MB1010C0C28AB7BAED7A18405BD6BF2@CWLP265MB1010.GBRP265.PROD.OUTLOOK.COM>
 <c6bd6279-b344-445d-bfcd-aeebd941b02f@gmail.com>
 <CANr4FXc=ZRocRcdStaA-5vN811e+czLR5Ajp3Uo7_U-3djtqpQ@mail.gmail.com>
 <CA+WbeBPYcZv+vjf7qD9duQ6hABmXFyTCkVuejE5P1GqVfG_tBg@mail.gmail.com>
In-Reply-To: 
 <CA+WbeBPYcZv+vjf7qD9duQ6hABmXFyTCkVuejE5P1GqVfG_tBg@mail.gmail.com>
From: Girish Konda <girish.sai1@gmail.com>
Date: Wed, 7 Oct 2026 12:51:09 -0700
Message-ID: 
 <CAMW0qhjO+6wcL41BqD8-zd5wu4yLqijhHkFnYtopFdQKUeRLnA@mail.gmail.com>
To: Francesco Marinoni Moretto <francesco.marinoni.moretto@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e9efcb065d457186"
Message-ID-Hash: QNI3FJEAG2UYYAHZUOBS23T6ISQFDGS3
CC: bn@agentcommunity.org, d.king@lancaster.ac.uk, enrique@somoza.co,
 dawn@ietf.org, adrian@olddog.co.uk
Precedence: list
Subject: [Dawn] Re: [External] DAWN Coordination: Discovery Information and Trust
 Artifact Pointers
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dawn/Ce73ar_tEl0XO2FE41sdNKAGjc8>

--000000000000e9efcb065d457186
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Folks,

A couple of comments on the by-reference requirements, both on the
unresolved case.

   1. *Three Causes, One Reported Outcome:* Francesco=E2=80=99s second requ=
irement
   separates a reference that doesn=E2=80=99t resolve from one the discover=
ing
   entity=E2=80=99s own retrieval policy blocked. There=E2=80=99s 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=E2=80=99s 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-stat=
e/>.
   Section 3 is the two-value problem and Section 4.2 is the cross-domain c=
ase
   where a profile is identified but not held. The surface is discovery rat=
her
   than authorization and the shape doesn=E2=80=99t change.
   2. *A Closed Set on Both Sides:* Balazs=E2=80=99s 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 th=
e
   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=E2=80=99t be compared.

Thanks,
Girish


On Tue, Sep 29, 2026 at 12:14=E2=80=AFAM Francesco Marinoni Moretto <
francesco.marinoni.moretto@gmail.com> wrote:

> Bal=C3=A1zs, Dan, Enrique,
>
> Thanks, Bal=C3=A1zs, 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 fail=
s.
>
> Dan, Adrian, with -01 expiring on 30 October: if the second option works
> for you, Bal=C3=A1zs 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 <bn@agentcommunity.org>
> 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 whe=
n
>> 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, n=
o
>> chained lookups. No redirects followed during verification; a cross-orig=
in
>> redirect after discovery needs policy or user approval. A small fixed se=
t
>> of failure outcomes, so "unresolvable" has defined behaviour. The result
>> also says whether it came from DNS or the HTTPS fallback, so local polic=
y
>> 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 requireme=
nts.
>>
>> On Enrique's question: I'd keep the minimum verification material by
>> value. We carry a public key in the record. The endpoint proves possessi=
on
>> on the first request the client makes anyway, and in v2 it can also conf=
irm
>> 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 no=
t
>> be allowed to make is fragile.
>>
>> Happy to help with text.
>>
>> Bal=C3=A1zs
>>
>> On Fri, Sep 25, 2026 02:53 PM, Francesco Marinoni Moretto <
>> francesco.marinoni.moretto@gmail.com> 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 indirectio=
n
>>>      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 resolv=
e,
>>>      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 th=
e
>>> > list. Agree that it=E2=80=99s 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 minimu=
m
>>> > 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 discover=
y
>>> > 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 <enrique@somoza.co>
>>> > *Sent:* 07 September 2026 16:17
>>> > *To:* dawn@ietf.org
>>> > *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 wit=
h
>>> > 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 =E2=80=94 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 =C3=A8 stata esaminata alla ricerca di virus dal software
>>> antivirus Avast.
>>> www.avast.com
>>> _______________________________________________
>>> Dawn mailing list -- dawn@ietf.org
>>> To unsubscribe send an email to dawn-leave@ietf.org
>>>
>> _______________________________________________
> Dawn mailing list -- dawn@ietf.org
> To unsubscribe send an email to dawn-leave@ietf.org
>

--000000000000e9efcb065d457186
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div id=3D"m_1498538338451760223kondv-draft"><div>Hey Folk=
s,</div><div><br></div><div>A couple of comments on the by-reference requir=
ements, both on the unresolved case.</div><ol><li><b>Three Causes, One Repo=
rted Outcome:</b> Francesco=E2=80=99s second requirement separates a refere=
nce that doesn=E2=80=99t resolve from one the discovering entity=E2=80=99s =
own retrieval policy blocked. There=E2=80=99s a third, where the reference =
resolves and the record is absent. All three end as no discovery result, an=
d they have different owners and different retries. A requirement that spec=
ifies only behaviour still lets a discovering entity report them identicall=
y, and that=E2=80=99s the state every later consumer inherits.<br><br>I hav=
e an Internet-Draft in AgentProto on the same distinction, <a href=3D"https=
://datatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state/">draft=
-konda-agentproto-evaluation-state-00</a>. Section 3 is the two-value probl=
em and Section 4.2 is the cross-domain case where a profile is identified b=
ut not held. The surface is discovery rather than authorization and the sha=
pe doesn=E2=80=99t change.</li><li><b>A Closed Set on Both Sides:</b> Balaz=
s=E2=80=99s AID v2 carries a small fixed set of failure outcomes, which is =
what makes the distinction checkable rather than advisory. draft-gilda-wims=
e-agent-audit-record is closing the same kind of set on the verifier side r=
ight now.</li></ol><div>We should align the two vocabularies while both are=
 still open, or a discovery failure and an evaluation failure end up record=
ed in terms that can=E2=80=99t be compared.</div><div><br></div><div>Thanks=
,</div><div>Girish</div><div><br></div></div><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 29, 2026 at 12=
:14=E2=80=AFAM Francesco Marinoni Moretto &lt;<a href=3D"mailto:francesco.m=
arinoni.moretto@gmail.com" target=3D"_blank">francesco.marinoni.moretto@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><div dir=3D"auto">Bal=C3=A1zs, Dan, Enrique,<br=
><br>Thanks, Bal=C3=A1zs, that is useful twice over. It narrows what the by=
-reference change was meant to do: a single pointer to a capability descrip=
tion for REQ-PROP-9, not chains.<br>And AID v2 shows the second option can =
be met in practice: one hop, no redirects during verification, a fixed set =
of failure outcomes.<br>That answers the obvious worry that a depth limit i=
s easy to write and hard to ship.<br><br>On Enrique&#39;s question, your po=
int and the two requirements fit together. The minimum verification materia=
l stays by value, anything richer sits behind a reference, and that referen=
ce is then covered by the depth limit and the failure behaviour.<br>The min=
imum never depends on a fetch the client may not be allowed to make, and ev=
erything behind it has defined behaviour when that fetch fails.<br><br>Dan,=
 Adrian, with -01 expiring on 30 October: if the second option works for yo=
u, Bal=C3=A1zs has offered to help with text and I&#39;m glad to draft it w=
ith him for -02, and you place and number it as you see fit.<br><br>Frances=
co Marinoni Moretto<br>Independent</div></div><br><div class=3D"gmail_extra=
"><div>On Fri, Sep 25, 2026 01:40 PM, Balazs Nemethi &lt;<a href=3D"mailto:=
bn@agentcommunity.org" target=3D"_blank">bn@agentcommunity.org</a>&gt; wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><div dir=3D"auto">Hi Francesco, Dan, Enrique,<br><br>When I raised the b=
y-reference point back in April it was only about REQ-PROP-9. Read strictly=
, that requirement could force capability data into the discovery record it=
self. I wanted a single pointer to the capability description (an agent car=
d, an MCP manifest or something) to count as well. Chains were not in scope=
, and &quot;usability&quot; was not my wording. So I&#39;d back Francesco&#=
39;s second option: a depth limit, defined behaviour when a reference canno=
t be resolved, and defined behaviour when the client is not allowed to fetc=
h it.<br><br>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 wa=
lking, no chained lookups. No redirects followed during verification; a cro=
ss-origin redirect after discovery needs policy or user approval. A small f=
ixed set of failure outcomes, so &quot;unresolvable&quot; has defined behav=
iour. The result also says whether it came from DNS or the HTTPS fallback, =
so local policy can decide what to accept.<br><br>None of that is DNS-speci=
fic. DNS has a role because the domain owner already controls it, but anoth=
er mechanism could meet the same requirements.<br><br>On Enrique&#39;s ques=
tion: I&#39;d keep the minimum verification material by value. We carry a p=
ublic key in the record. The endpoint proves possession on the first reques=
t the client makes anyway, and in v2 it can also confirm it serves the doma=
in 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 f=
ragile.<br><br>Happy to help with text.<br><br>Bal=C3=A1zs</div></div></div=
><br><div class=3D"gmail_extra"><div>On Fri, Sep 25, 2026 02:53 PM, Frances=
co Marinoni Moretto &lt;<a href=3D"mailto:francesco.marinoni.moretto@gmail.=
com" target=3D"_blank">francesco.marinoni.moretto@gmail.com</a>&gt; wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Dan, Enrique,<br>
<br>
Picking up Dan&#39;s offer to record following a reference as an open quest=
ion:<br>
I think the requirements draft already has the spot where it gets answered,=
<br>
and right now that spot is empty.<br>
<br>
Section 1.1 of draft-king-dawn-requirements-01 allows the indirection <br>
outright:<br>
<br>
=C2=A0=C2=A0 =C2=A0 &quot;A discovery mechanism may return such information=
 directly or<br>
=C2=A0=C2=A0 =C2=A0 provide a reference to another resource from which the =
information<br>
=C2=A0=C2=A0 =C2=A0 can be obtained, provided that the requirements for aut=
henticity,<br>
=C2=A0=C2=A0 =C2=A0 integrity, interoperability, and usability are satisfie=
d.&quot;<br>
<br>
Three of those four conditions have requirements behind them.<br>
Authenticity and integrity are REQ-SEC-1. Interoperability is carried<br>
by REQ-PROTO-4. Usability has none: the word occurs exactly once in<br>
the whole document, in the sentence above, and no requirement in<br>
Section 3 names it.<br>
<br>
The clause is load-bearing. &quot;Either directly or by reference&quot; app=
ears<br>
in REQ-PROP-2, REQ-PROP-3, REQ-PROP-8, REQ-PROP-9 and<br>
REQ-PROP-12, so four MUST-level requirements and one SHOULD<br>
can be satisfied by a reference, and all five inherit a condition the<br>
document does not define.<br>
<br>
Dan, your point about layering is the reason this matters rather than<br>
an objection to it. If following the reference is an application<br>
exchange, then it sits outside discovery, and the usability condition<br>
in 1.1 rests on a step the document does not specify. As drafted it<br>
cannot be checked: there is no way to tell whether a discovery<br>
mechanism satisfies it.<br>
<br>
Two ways out, and the authors and the list should pick, not me.<br>
Either define usability as a term, which would mean Section 2 and<br>
draft-farrel-dawn-terminology, where the other terms come from, or<br>
drop the word from 1.1 and replace it with requirements that can be<br>
verified. If the second, this is the substance I would suggest, with<br>
the numbering and the placement left to you:<br>
<br>
=C2=A0=C2=A0 =C2=A0 A discovery mechanism MUST specify the maximum depth of=
 indirection<br>
=C2=A0=C2=A0 =C2=A0 a discovering entity is required to follow, and the beh=
aviour when<br>
=C2=A0=C2=A0 =C2=A0 that depth is exceeded.<br>
<br>
=C2=A0=C2=A0 =C2=A0 A discovery mechanism MUST specify the behaviour of a d=
iscovering<br>
=C2=A0=C2=A0 =C2=A0 entity when a reference obtained through discovery does=
 not resolve,<br>
=C2=A0=C2=A0 =C2=A0 including the case where the discovering entity&#39;s o=
wn retrieval<br>
=C2=A0=C2=A0 =C2=A0 policy, rather than the network or the server, prevents=
 resolution.<br>
<br>
The last clause of the second is the part I would not drop.<br>
Retrieval policy is now a real constraint and not a hypothetical one.<br>
<br>
OpenAI documented in January 2026 that an agent checks &quot;whether that<b=
r>
URL matches a URL previously observed by the independent index&quot;, and<b=
r>
that when it does not match, &quot;we treat it as unverified and do not<br>
trust it immediately&quot;. A conformant reference, correctly published and=
<br>
reachable on the network, is still not followed automatically if no<br>
independent index has seen it. A discovering entity that behaves this<br>
way is acting reasonably, and the requirements draft currently says<br>
nothing about what it should do instead.<br>
<br>
Enrique asked whether the minimum discovery information includes a<br>
pointer to a later-stage trust artifact set, or whether locating those<br>
artifacts is the consumer&#39;s problem. That is a closely related<br>
question: whichever way it lands, the condition attached to every<br>
reference the document already allows still needs a definition or a<br>
replacement.<br>
<br>
On credit, the -01 announcement says the revision was mostly &quot;to<br>
address comments and suggestions from Jim Mozley and Balazs Nemethi&quot;,<=
br>
with by-reference as its main change, and Section 8 acknowledges both<br>
of them for the discussions that shaped the document. The gap in<br>
&quot;usability&quot; is my reading, and not something either of them raise=
d.<br>
<br>
Happy to write either the definition or the two requirements as text,<br>
whichever the authors prefer.<br>
<br>
Francesco Marinoni Moretto<br>
Independent<br>
<br>
<br>
Il 10/09/2026 12:31, King, Daniel ha scritto:<br>
&gt;<br>
&gt; Hi Enrique,<br>
&gt;<br>
&gt; Thanks for this! I only just noticed the email when I was scanning the=
 <br>
&gt; list. Agree that it=E2=80=99s more likely question(s) to put to the <b=
r>
&gt; Architecture work rather than to the use cases.<br>
&gt;<br>
&gt; For what it&#39;s worth, the 01 use cases draft (just posted) already =
<br>
&gt; assumes discovery can provide an earlier reference, and treats <br>
&gt; following it as an application exchange. Does it belong in the minimum=
 <br>
&gt; info, no strong opinion (especially from a use case perspective), <br>
&gt; happy to record it as an open question though.<br>
&gt;<br>
&gt; One aspect we did underline, is in the minimum set then it&#39;s disco=
very <br>
&gt; information (to start the relationship), then authenticity, integrity =
<br>
&gt; and visibility, et al. is layered afterwards, depending on the <br>
&gt; intent/task.<br>
&gt;<br>
&gt; I will look at draft-somoza-dmsc-atn-agent-trust-negotiation and <br>
&gt; comment accordingly.<br>
&gt;<br>
&gt; BR, Dan.<br>
&gt;<br>
&gt; *From:*Enrique Somoza &lt;<a href=3D"mailto:enrique@somoza.co" target=
=3D"_blank">enrique@somoza.co</a>&gt;<br>
&gt; *Sent:* 07 September 2026 16:17<br>
&gt; *To:* <a href=3D"mailto:dawn@ietf.org" target=3D"_blank">dawn@ietf.org=
</a><br>
&gt; *Subject:* [External] [Dawn] DAWN Coordination: Discovery Information =
<br>
&gt; and Trust Artifact Pointers<br>
&gt;<br>
&gt; *This email originated outside the University. Check before clicking <=
br>
&gt; links or attachments.*<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; Not a charter comment... I&#39;m aware external review closed on 31 <b=
r>
&gt; August. This is a coordination note for whenever the WG gets going, <b=
r>
&gt; since the charter has a coordination section and the boundary I want <=
br>
&gt; to raise is one DAWN has already drawn itself.<br>
&gt;<br>
&gt; draft-kay-dawn-use-cases puts it well: discovery is not a statement <b=
r>
&gt; that the discovered entity is safe, competent, or authorised, and it <=
br>
&gt; supplies discovery information and trust indicators while policy and <=
br>
&gt; selection are later functions. The proposed charter is consistent with=
 <br>
&gt; that, holding identity management and trust evaluation methods out of =
<br>
&gt; scope for the initial phase.<br>
&gt;<br>
&gt; I think that boundary is right. My suggestion is only that the <br>
&gt; Architecture document be explicit about where it falls. When the WG <b=
r>
&gt; specifies the minimum discovery information, there is a question of <b=
r>
&gt; whether that minimum includes a pointer to a later-stage trust <br>
&gt; artifact set, or whether locating those artifacts is entirely the <br>
&gt; consumer&#39;s problem. Either answer works. Leaving it unstated is wh=
at <br>
&gt; costs, because a consumer that has to fetch policy artifacts out of <b=
r>
&gt; band ends up round-tripping twice for what could have been one <br>
&gt; indirection, and adding the pointer later is a format change.<br>
&gt;<br>
&gt; I have a stake in the answer, so declaring it: I author <br>
&gt; draft-somoza-dmsc-atn-agent-trust-negotiation, which specifies the <br=
>
&gt; later-function side =E2=80=94 capability, delegation, provenance, and =
a signed <br>
&gt; receipt of what two parties agreed. It is deliberately <br>
&gt; discovery-agnostic and takes a discovered, authenticated identity as <=
br>
&gt; input, so it does not need anything from DAWN. But it is one of the <b=
r>
&gt; consumers that would use such a pointer if it existed, which is why <b=
r>
&gt; I&#39;d rather the question be answered on purpose than by default.<br=
>
&gt;<br>
&gt; Happy to review the Architecture or Use Cases documents from the <br>
&gt; consuming side if that is useful.<br>
&gt;<br>
&gt; Enrique Somoza<br>
&gt;<br>
&gt; Independent<br>
&gt;<br>
<br>
-- <br>
Questa email =C3=A8 stata esaminata alla ricerca di virus dal software anti=
virus Avast.<br>
<a href=3D"http://www.avast.com" rel=3D"noreferrer" target=3D"_blank">www.a=
vast.com</a><br>
_______________________________________________<br>
Dawn mailing list -- <a href=3D"mailto:dawn@ietf.org" target=3D"_blank">daw=
n@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:dawn-leave@ietf.org" targ=
et=3D"_blank">dawn-leave@ietf.org</a><br>
</blockquote></div></div>
</blockquote></div></div></div>
_______________________________________________<br>
Dawn mailing list -- <a href=3D"mailto:dawn@ietf.org" target=3D"_blank">daw=
n@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:dawn-leave@ietf.org" targ=
et=3D"_blank">dawn-leave@ietf.org</a><br>
</blockquote></div>

--000000000000e9efcb065d457186--