Blake, thanks. I agree this belongs in the problem statement. Authenticating the client doesn't tell you who gave the instruction. Neither does committing the approved Intent.
Alex raised the same gap in his review last week. I said I'd open an issue for a provenance evidence type (#939 <https://github.com/mcguinness/mission-bound-authorization/issues/939>). That issue became the experimental draft Mission Request Provenance <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-request-provenance.html>. It covers part of what you describe. The draft treats the originator as separate from the presenter. A signer the AS trusts for that person signs the assertion. The signer is either an intake that authenticated the person or the person's enrolled device key. You're right that Submission Evidence §4.2 won't carry evidence across a change of Intent unless the evidence type defines a lineage. The draft doesn't define one, and doesn't need to. The intake captures the instruction before shaping, then signs once the shaped Intent exists. If the Intent changes again, it needs a fresh assertion. The draft has limits. The AS verifies who attested and which Intent the assertion covers. It doesn't verify what the instruction said. It doesn't verify that the shaper used it, or that the Intent reads it faithfully. A Mandate's commitment doesn't change that. There's no implementation yet. Please comment on #939 <https://github.com/mcguinness/mission-bound-authorization/issues/939>, and feel free to write up the requirement there. I'd especially like your view on whether parties downstream of the AS need to verify the original instruction themselves. Thanks, Karl On Wed, Oct 7, 2026 at 8:14 PM Blake Morrison <blake= [email protected]> wrote: > Hi Dapeng, Karl, Yaron, Ron, Kieran, > > Interested. I'd like to add one piece to the problem statement. > > Both layers in the thread check against the approved Mission. That's > Yaron's authority metadata before issuance and Ron's record comparison > after it. But the Mission starts as the agent's Intent. The user said > "buy product A" before any Intent existed and what they approve is the > agent's reading of it. Karl's Mandate commits to that approved intent > so it carries the reading rather than the instruction. > > That piece is evidence of the instruction that started the Mission. > 4.3 of Karl's submission evidence draft has the exchange establish the > presenter which is the client. The person who gave the instruction > isn't a party to it. The evidence also has to survive shaping and 4.2 > only lets it name the shaped intent_hash if the type defines a lineage > from input_digest. > > I'm happy to write the requirement up for whichever draft takes it. > > Blake > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
