Delegation

Delegation is the relation "this person authorizes this agent to act for them". Before any question about tools or resources, Xokepoint checks this relation. In the authorization model it is the tuple agent#delegator@user (or @service_account) in OpenFGA, described in Authorization model.

Consent and expiration are not set per person. They belong to the scope of each identity provider in the agent's permission document: the administrator picks the people or services of one IdP, records the consent once for that group and, optionally, an end date. Publication copies that date into every delegation tuple of the scope, and a scope without consent is not published.

The consent has two sources. For the subjects listed in the scope, it comes from the administrator: the Admin records who confirmed it and when, from the signed-in user. For a coding harness, it comes from the person: the scope names the IdP groups whose members can consent, and each person accepts at login (Connect a coding harness). That interactive consent is a record of its own, with the person, the group and an expiry bounded by the scope, and publication adds one delegation tuple for each active one. A person blocked on the agent has no delegation tuple, whatever the source. Some IdPs can prove a delegation themselves (Entra On-Behalf-Of, Okta Cross App Access, the act claim in Keycloak), and the permission document already has room for a consent whose source is the IdP, but the authorization server does not accept those proofs yet: a token exchange with an actor_token is refused.

The end date is a condition of the relation itself: OpenFGA evaluates it with the current time on every query, and an expired delegation simply stops existing for the decision.

Delegation is checked at two moments, and the second one is what matters for revocation:

If the check happened only at the exchange, revoking a delegation would wait for the token to expire. Because it repeats on every call, the agent loses access on the call after the revocation.