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

["King, Daniel" <[e-mail]>]

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