[mcguinness]

Proposes the minimal answer in #746. Draft, and it answers a scope question the issue raises first — see below.

Off main. Merges clean with #744.

The gap

Approver eligibility, including delegated approver authority, is evaluated once, before approved is returned. Current Approval Status requires the PDP to check the approval's own state at re-evaluation: revoked, cancelled, superseded, invalidated. Nothing re-examines the authority that produced the approval.

A manager approves a standing grant with a thirty-day approved_until. The next day their delegated authority lapses. The approval record is untouched, so it is not revoked, cancelled, superseded or expired. Every later re-evaluation performs the required status check, finds the approval clean, and permits — for twenty-nine days, with every rule in this profile satisfied.

What changes

One addition to what the approval record must let the PDP determine: whether the approval's validity depends on the approver's authority remaining current. The two cases are named point_in_time, where the approval records what an authorized approver confirmed when they confirmed it and stands afterwards, and continuing, where its validity depends on that authority remaining current.

Worth being precise about what that obliges. The existing sentence says the record must "contain, or allow the PDP to determine" its contents, so this adds a distinction the PDP must be able to resolve, not a stored field with a required name. The names are there so that two implementations that do represent it agree on what the values mean.

That is the whole mechanism. It defines no revocation, requires the PDP to reach nothing new, and makes no check mandatory. @Projetxana's qualification on #663 is what forces this shape: withdrawal of authority should invalidate an approval only where the applicable semantics require that authority to remain current. Re-checking the approver is wrong for an attestation; silence is wrong for a derivative grant. The profile models neither, so it records the distinction instead of choosing.

A value rather than a boolean, because the distinction is a kind and two values that each say what they mean age better than true and false.

What it is honest about

It applies to both verification paths, as the rest of the record does. A PDP resolving approval.id from trusted state determines the value by lookup; a PDP verifying a self-contained approval.state determines it from that payload. What this profile cannot supply for the second path is an interoperable representation, because it defines no approval-state payload at all (#659) — but nothing stops a deployment-specific signed payload from carrying it today, which is how every other piece of approval-state information already travels. So the semantic requirement covers both and the by-value representation stays deployment-specific. This is the same shape as #659 one level up, which the issue notes: a signed artifact proves what was true at signing and cannot prove nothing has changed since.

It does not make anything happen. A deployment that marks approvals continuing and never checks is exactly where it was. The value identifies the approvals for which an audit needs evidence of continuing authority. It does not provide that evidence, and nothing here requires the authority to have been checked.

The decision this takes

The issue's first recommendation is to decide whether this profile owns the problem at all, and notes it is arguably identity-lifecycle territory. This PR answers yes, for the recording only. Deciding scope by merging a field is backwards, so the alternative is on the table: close #746 as out of scope and let a deployment profile carry it.

My argument for recording it here is that Approver Eligibility already names "delegated approver authority", so this profile has already acknowledged the second kind of approval exists. It just never says what happens when the delegation lapses.

Explicitly not here, and rejected in the issue: requiring the PDP to re-validate approver authority, defining an authority status or revocation protocol, and defining transitive path resolution.

Costs

No BCP 14 keywords added or removed, 315 either side. The distinction joins the existing MUST list for the approval record, so it is required of every conforming Access Request Service, which is a real conformance change for a one-value gain. Making it optional instead would mean an auditor cannot rely on it, which is most of the value.

Checks

kramdown-rfc2629 and xml2rfc --text build clean. normative_diff.py against main shows the record-contents MUST reworded with its replacement and nothing removed. {{?RFC9396}} is the only unresolved reference and is pre-existing.