[Vcon] Re: Lawful basis withdrawn mid-session: which boundary does it bind?

[Thomas Howe <[e-mail]>]

Vernon,

You're correct—I reviewed all the references, and they check out. The draft enforces withdrawal in 11.3 but doesn't let a processor observe it. Everything a processor consults in sections 5 and 6—covering expiration, purpose_grants.granted, and content_hash—becomes immutable after signing. Withdrawal remains an obligation, audit example, and SCITT event, which lifecycle-01 states isn't in the container. A conforming implementation could honor withdrawal—or not—and still meet Section 6's MUST requirements.

Your point about immutability is also correct. I can't toggle granted to false because 10.3 mandates signing, and 6.1 rejects hash mismatches. A superseding attachment under 6.4 works for updated containers but not for holders of the original.

You almost caught another issue. In 7.2, item 5, implementations must cache lawful basis states in intervals. As written, caching is mandatory. What I meant was a staleness ceiling. Changing it to "MUST NOT rely on cached state older than status_interval" fixes it and gives status_interval meaningful semantics.

The draft must define what a revocation query to a SCITT service returns. SCRAPI specifies statement registration and receipt retrieval but lacks an is-this-revoked query. The draft should add: retrieve statements about a given vCon subject and treat a registered vcon_consent_revoked as authoritative from its timestamp onward.

To your three questions:

* The evaluation boundary is undecided. I think it should apply per processing operation, not per session. Lifecycle-01 includes storage and disclosure, making a session-based boundary impractical for long sessions.

* Status_interval needs processing semantics. Burying it as a convention in conditions is insufficient. Tying it to the registry with a fail-closed rule addresses the null expiration gap and freshness concerns.

* Withdrawal should function as a state processors consult, not just an obligation. It can't reside in the signed attachment but should live in the registry, with the container pointing to it.

I'll also fix the dependency graph. Lifecycle isn't referenced in lawful-basis-02, breaking the graph where semantics are missing.

On your editorial feedback: 10.3's strongest integrity MUST will move to a more prominent spot. Regarding SCRAPI, the reference title should be "SCITT Reference APIs," not "SCITT Reference REST API." I'll confirm the latest version numbers on datatracker.

If you draft the revocation resolution rule and status_interval semantics, I'll integrate them into sections 6 and 7. I'd suggest leaving ISO 42001 and NIST AI RMF mappings as supplementary material—they age faster than the standard.

Thank you for your thoughtful message. Flagging your own overstatements helped me take action faster.

Thomas

=====================
Thomas Howe ( http://www.lightandelectric.com )
[phone]

Sent via Superhuman ( https://superhuman.com/refer/r14chm1w?utm_medium=signature&utm_source=product )

On Mon, Aug 10, 2026 at 1:23 PM, Vernon < [e-mail] > wrote:

> 
> 
> 
> Hello,
> 
> 
> 
> 
> Vernon Wharff. I build pre-execution authorization controls for AI agents,
> aimed at firms that have to evidence a control to an auditor rather than
> describe it. Over the weekend, I read
> draft-howe-vcon-lawful-basis-02 against
> draft-howe-vcon-agent-session-00. One question arose from it that I cannot
> answer from the text.
> 
> 
> 
> Section 6 defines five processing requirements. Only Section 6.2 tests
> temporal validity, and implementations MUST perform that check "before
> processing". Section 6.5 reaches a status check in its third item,
> "Check external system lawful basis status via API calls", at SHOULD level
> with no stated trigger. The subsection opens "Implementations SHOULD
> verify proof mechanisms when present", and proof_mechanisms is optional
> under Section 5.2.2, so an attachment that omits it never reaches that
> check at all. Section 5.2.4 defines the external_system proof type as
> "Lawful basis recorded in external system with API verification" and
> proof_data as "Object containing proof-type-specific data". No endpoint,
> schema, or response semantics follow. I read the registry object at 5.2.2
> as a separate thing, since it describes a transparency ledger rather than
> a consent-status query.
> 
> 
> 
> Section 5.2.2 also defines status_interval as a duration for revalidation
> intervals. Two places rely on it. Item 4 of the Section
> 6.2 MUST list requires implementations to "Support null expiration for
> indefinite validity subject to revalidation intervals". Section 13 credits
> expiration controls and revalidation intervals with ensuring
> "a lawful basis cannot be misused beyond its intended temporal scope".
> Nothing states what a processor does when an interval elapses, so an
> indefinite basis rests on a mechanism with no processing semantics.
> 
> 
> 
> Withdrawal is mandatory and undefined. Section 11.3 puts it under
> "Implementations MUST support data subject rights including", as
> "Withdrawal: Provide mechanisms for revocation of a lawful basis". Section
> 11.2 claims alignment with "GDPR Article 7: Conditions for lawful basis
> including withdrawal mechanisms", in a document that defines no withdrawal
> mechanism. Section 10.4 recommends an audit record listing "revoked" among
> its examples. Sections 5 and 6 then carry no withdrawn state, no
> processing rule that consults one, and no error for one. Section 8 defines
> LawfulBasisExpiredError and no equivalent.
> 
> 
> 
> I looked for a place to put such a state and could not find one that
> works.
> 
> 
> 
> 
> Setting granted to false in an existing attachment is not available.
> Section 10.3 requires that "All lawful basis attachments MUST be integrity
> protected using vCon signing mechanisms". A mutation breaks that
> signature, and where content_hash is present it also fails Section 6.1,
> which requires implementations to "Reject processing if hashes do not
> match".
> 
> 
> 
> 
> A second attachment does work, and I want to state that rather than
> overclaim. Section 6.4 tells a processor to "Apply most restrictive
> permission when multiple grants apply". A later granted: false therefore
> wins for any holder who receives the new container. It cannot reach copies
> already distributed. Every holder of the earlier signed vCon still
> validates a clean grant, and nothing tells that holder a superseding
> attachment exists.
> 
> 
> 
> 
> The one concrete withdrawal state in this document set sits outside the
> container. draft-howe-vcon-lifecycle-01 Section 5 defines
> vcon_consent_revoked and says those events are "not intended to be stored
> within the vCon itself". lawful-basis-02 does not reference that document
> in either reference list.
> 
> 
> 
> 
> Retention does not narrow the question. Section 2 of lifecycle-01 defines
> processing to include "collection, storage, use, disclosure, and
> deletion". A retained recording is therefore under continuous processing,
> so the boundary matters for a plain recording as much as for an agent
> session.
> 
> 
> 
> 
> Agent sessions make it sharpest. Section 2.1 of agent-session-00 defines
> an Agent Session as a single bounded run with a defined start and end,
> identified by a session identifier. Section 9 requires that
> "An agent session that processes personal data MUST be governed by a
> documented lawful basis". The attachment that would carry it is only
> recommended: "Implementations SHOULD include a lawful_basis attachment",
> and the three purpose names sit under that SHOULD. So a conformant agent
> session can hold a documented lawful basis that exists on paper and
> nowhere in the container.
> 
> 
> 
> Where the attachment is present, one grant covers a run that may make many
> tool calls. "Before processing" then has two readings that give opposite
> answers. Read it as the run boundary, and a subject who withdraws at
> minute two of a forty-minute run gets nothing until the run ends.
> 
> 
> 
> 
> Read it as the tool-call boundary, and Section 7.2 pulls the other way.
> Implementations that support registries MUST "Cache lawful basis state
> within configured intervals". A cached grant can report valid after a
> withdrawal the processor has already received. That holds whether the
> interval bounds a staleness window or creates one.
> 
> 
> 
> 
> Section 9 also closes with a live prohibition. Where a session was
> authorized only under a basis that prohibits redistribution, the vCon
> "MUST NOT be transmitted to parties outside the scope of that grant". A
> withdrawal changes what triggers that MUST NOT, and nothing states the
> moment it starts binding.
> 
> 
> 
> This is a governance question rather than a cryptographic one, and I am
> not proposing a mechanism. Two conforming implementations can honor a
> withdrawal at different moments today , and both can point at Section
> 6.2.
> 
> 
> 
> Three questions.
> 
> 
> 
> 
> Is the evaluation boundary deliberately left to implementations, or is it
> an open item?
> Should status_interval carry processing semantics? A purpose with
> real-time withdrawal obligations could then require uncached state, while
> a recording purpose does not. conditions in Section 5.2.3 could carry this
> by convention, and a convention seems weak for something that decides
> whether a withdrawal binds.
> Does the group want withdrawal expressed as a state a processor consults
> before processing? Today it is an obligation in Section 11, an audit record
> in Section 10.4, and an event outside the container.
> 
> 
> 
> Two editorial notes, both in Section 14.1. lawful-basis-02 normatively
> references draft-ietf-vcon-vcon-core-02 from January 2026, and core is now
> at -03. It also normatively references draft-ietf-scitt-scrapi-07 from
> November 2025, under that draft's former title. SCRAPI is now at
> -11 and sits in the RFC Editor queue, so what breaks on publication day is
> the citation's correctness rather than its resolution.
> 
> 
> 
> One structural note. The MUST at 10.3 is the strongest integrity
> requirement in the document. It sits under a heading about secure
> communication channels, whose background paragraph covers interception in
> transit. The requirement is broader than its heading suggests.
> 
> 
> 
> 
> I am happy to write text for any of this. Separately, I maintain a control
> map against ISO/IEC 42001 Annex A and the NIST AI RMF functions. If it is
> useful to the group, I will map the purpose-grant model onto that control
> map and contribute the result. The mapping does not exist yet, so treat it
> as an offer of work rather than of a document.
> 
> 
> 
> 
> Vernon Wharff
> Sigil Open Framework
> 
> 
> 
> --
> Vcon mailing list -- vcon@ ietf. org ( [e-mail] )
> To unsubscribe send an email to vcon-leave@ ietf. org ( [e-mail]
> )
> 
> 
>