In this model the resource owner, knowing delegatee's full identification, creates an access control rule at the resource, i.e. sticky policy, that simply authorizes the delegatee to access the resource.
The ability to assign access to other user can be regulated by policies that are checked by the sticky policy interface, e.g. by consulting a PDP.
When delegatee accesses the resource, he identifies himself using the usual token passing flow, see Section 3.2, and the PDP is able to match his identity to the sticky policy authorizing the access.
Difficulties are
The Delegator has to have a solid identifier for the delegatee. This may be difficult for a human to know and accurately enter. It is possible to offer to the delegator a browsing or search interface of all potential delegatees, but such list may be unacceptable from data protection perspective and can be difficult to implement in a distributed way.
A better alternative may be to adopt the invitation steps 1-4 from section 3.3.1 and modify the step 4 so that it edits the access control rule.
The resource has to have a sticky policy editing interface and access to this interface needs to be well controlled. Online editing of policies increases exposure and potential for compromise.
If policy editing interface is centralized (e.g. in Dashboard), the identification of the resource to which the policy applies may be difficult. This can be solved to an extent by Discovery. The the policy editing interface of the resource would have to be web service based, with proof of presence of the delegator.
Privacy is poor as the requirement to know delegatee's identity widely excludes pseudonymous approaches.
Invitations are not supported