[Agentproto] Re: [agentproto] Requirement question: binding resumed dialog context to current authorization and freshness

[Vaishnavi Gudur <[e-mail]>]

Hi Tiru,

Thanks, the updated B1-7 reads well to me and covers the case I raised. I
have nothing further on it.

Regards,
Vaishnavi Gudur
Personal contribution; views my own
https://www.google.com/url?q=https://vgudur-dev.github.io/&source=gmail&ust=1791873109018000&sa=E

On Sun, Oct 11, 2026 11:08 PM, tirumal reddy <[e-mail]> wrote:

> Hi Vaishnavi,
>
> Good catch, thanks. We will update B1-7 in the next revision as follows:
>
>   B1-7: On resumption, the protocol is required to enable the receiving
>   participant to verify that the party resuming the dialog is the
>   participant whose exchange was interrupted,
> *that the dialog context  presented is the current state of that dialog*,
> and that the dialog
>   has not been terminated or its authorization revoked. If any check
>   fails, the dialog is not resumed and the failure is signaled.
>
> Best Regards,
> -Tiru
>
> On Sat, 10 Oct 2026 at 22:19, Vaishnavi Gudur <[e-mail]>
> wrote:
>
>> Hi Tiru,
>>
>> Thank you for turning this into B1-7, and thanks to Lars and Girish for
>> sharpening it. Stating the two checks separately, and signaling the
>> failure, address the core of what I raised: a dialog that resumes, or
>> silently restarts, after the authorization behind it is gone.
>>
>> One narrow suggestion that keeps the mechanism out of the requirement. As
>> written, B1-7 lets the receiver check who is resuming and whether the
>> dialog is still authorized, but not which state is being resumed. A
>> participant who passes both checks could still present an earlier
>> checkpoint of the same dialog, or context from a different one. A clause
>> such as "and that the dialog context presented is the current state of that
>> dialog" would state the property, while how freshness or rollback is
>> detected stays with the protocol design, as you note.
>>
>> If you'd rather keep B1-7 as it is and track this separately, that works
>> for me too.
>>
>> Regards,
>> Vaishnavi Gudur
>> Personal contribution; views my own
>>
>> https://www.google.com/url?q=https://vgudur-dev.github.io/&source=gmail&ust=1791737291685000&sa=E
>>
>> On Fri, Oct 09, 2026 11:24 PM, tirumal reddy <[e-mail]> wrote:
>>
>>>  Hi,
>>>
>>> Thanks for the discussion. We added a separate requirement rather than
>>> amending B1-6: https://github.com/tireddy2/agentic-ai-ucreq2/pull/72
>>>
>>> B1-7: On resumption, the protocol is required to enable the receiving
>>> participant to verify that the party resuming the dialog is the participant
>>> whose exchange was interrupted, and that the dialog has not been terminated
>>> or its authorization revoked. If either check fails, the dialog is not
>>> resumed and the failure is signaled. The two conditions are stated as
>>> distinct checks, following Lars. Signaling the failure rules out a silent
>>> restart, following Girish. The three-state distinction and how freshness or
>>> rollback is detected are left to the protocol design.
>>>
>>> In line with the charter, the draft now uses dialog and dialog context
>>> throughout.
>>>
>>> Best Regards,
>>> -Tiru
>>>
>>> On Fri, 2 Oct 2026 at 11:45, Girish Konda <[e-mail]> wrote:
>>>
>>>> Hey Vaishnavi,
>>>>
>>>> A couple of comments on the proposed B1-6 amendment. I agree with Lars
>>>> that binding and current status rest on different evidence. Run together in
>>>> one clause, they'll be read as one check.
>>>>
>>>>    1. *The Refusal Branch Loses What the Requirement Protects:* The
>>>>    sentence ends "it SHOULD initiate a new context or return a distinct
>>>>    failure". Those aren't the same outcome for whatever is above the receiver.
>>>>    A distinct failure says the prior context couldn't be used. Starting a new
>>>>    context says nothing. From one level up it's indistinguishable from a
>>>>    dialog that had no prior context to resume. So the requirement forbids
>>>>    silent resumption and then allows silent restart. What it was protecting is
>>>>    lost one hop later. If the choice stays, the new-context branch needs to
>>>>    carry that it followed a failed resume.
>>>>    2. *Name the Third State in the Requirement, Not Only the Refusal:*
>>>>    A receiver told the authorization is withdrawn and a receiver that can't
>>>>    reach the issuer both fail to verify. The proposed text treats them the
>>>>    same, because both land in "cannot verify". They call for different
>>>>    behaviour though. A deployment that wants to resume on a stale-but-recent
>>>>    answer can't express that under one predicate. Separating "verified and
>>>>    withdrawn" from "could not establish" keeps the requirement testable.
>>>>
>>>> On the charter thread this is the same boundary from the lifecycle
>>>> side. If the working group takes the sentence, the two documents should use
>>>> one vocabulary for the three states.
>>>>
>>>> Thanks,
>>>> Girish
>>>>
>>>> On Thu, Oct 1, 2026 at 2:10 AM Lars Kersten Kroehl <lars=
>>>> [e-mail]> wrote:
>>>>
>>>>> Vaishnavi, your proposed sentence runs two properties together that
>>>>> rest on different evidence, and an implementer will treat them as one check.
>>>>>
>>>>> Binding to the authenticated parties, the dialog identifier and the
>>>>> authorization scope can be verified by the receiver against the context it
>>>>> holds. The current status of that authorization lives with the party that
>>>>> issued it, so a receiver handed a well-formed reference has no way to tell
>>>>> from the reference whether a cancellation, termination or revocation has
>>>>> happened since. A requirement that states both in one clause will be read
>>>>> as met once the binding verifies, and silent resumption returns through
>>>>> that door.
>>>>>
>>>>> Your second sentence already carries the refusal; adding the means
>>>>> would close it. A receiver that cannot verify the binding, or cannot
>>>>> establish current status by whatever means the protocol provides, refuses
>>>>> to resume silently. Alongside it, the document should say what a verified
>>>>> binding does not establish, so that a receiver stops short of reading it as
>>>>> evidence that the authorization still stands.
>>>>>
>>>>> Patrick Hopper's fourth item on the charter thread describes the same
>>>>> case from the detection side.
>>>>>
>>>>> Lars
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Agentproto mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>