Can a WAC grant let one person act on someone else's behalf?

Not in the sense that phrase usually means, and this page poses the question rather than claiming we solved it. Access control here names an agent, not a relationship.

What you can do today

Grant the other person's identifier access to the resource. That works, it is one call, and it is revocable, the enforcement was demonstrated with a before-and-after and a control.

So in the narrow sense: yes, a carer can read the record.

Why that is not delegation

The rule that results says one thing: this agent may read this resource.

It does not say on whose behalf. It does not say because she authorised it, or only for this purpose, or until the end of the month. It is delegation by copy: the helper is granted the same access the principal has, as themselves.

Three consequences, and the third is the one that matters in the settings people ask about:

1. No provenance. Nothing in the record connects the grant to the principal's intent.
2. No bounds. There is no purpose, no scope and no expiry on a grant, and our own listing does not even record when it was made.
3. No attribution in the trail. Afterwards, an audit cannot tell the principal's own action from the helper's. In guardianship, care or legal-representation scenarios that distinction is the entire question, and the model does not carry it.

The closest primitive, and why our interface withholds it

The vocabulary has a mode for handing over the ability to re-grant. It is closer to co-ownership than to delegation: the grantee can change who else has access, including removing you.

Our interface never grants it. It appears in our code exactly once, in the revoke path, set to false along with everything else. Two of four modes.

Withholding it is defensible for a mode that can lock the owner out. What is not defensible is withholding it silently, which is what we currently do, and this page is where that stops.

The vocabulary for real delegation exists in our own record, unused

Resolve a real identifier and the document carries capability_invocation and capability_delegation. Both are populated. Both point at the holder's own key, the same key that already serves authentication and assertion.

So the record expresses no separation of duties at all, and the delegation relationship names nobody else and grants nobody anything. Nothing on this surface reads it.

CONTROLS: two other identifier strings resolve to null, so the document above is a real record.

That is the honest state: the field for the concept exists, and it is doing no work.

What a real answer would need

A statement the principal signs, naming the delegate, the scope, the purpose and an expiry; presentable by the delegate; and verifiable by whatever is protecting the resource.

That is a credential shape, not an access-list shape. An access list answers may this agent read. A delegation answers is this agent entitled to act for that person, and within what limits, and the second cannot be squeezed into the first without losing the part that matters.

Whether the resource server should verify such a statement directly, or whether it should be exchanged for an ordinary grant that is then indistinguishable from any other, is exactly the open question. We have not answered it, and we are not going to pretend the choice is obvious.