If Delegatee's accurate identification can be known, the delegator can instruct a Delegation Service to create a signed (by Delegation Service) token for accessing his resource. The fact that he can make this delegation is checked against issuing policies, such as "data owner can delegate access to it".
The token can then be stored for future use in several places:
In Attribute Authority of the Resource Owner
In Attribute Provider of the Delegatee
In token store of the Delegation Service
When Delegatee accesses the resource, he can push the token, obtained from (2) or (3), to the web service that provides the resource. The token will identify the resource to which it applies, this is the Target Identity.
Sometimes the mere presence of the delegation token is sufficient for accessing the resource, this would be considered a bearer token.
However, in a more common case, the Delegatee also pushes a token identifying himself, e.g. a SSO token. This expresses the Subject Identity, i.e. the identity of the user performing the access. This allows the delegation token to be constrained to a user who can present token evidence of actually being the Delegatee. This is essentially a Holder-of-Key proof and produces strong audit trail that identifies who delegated and to whom.
Another variant is for the resource providing the web service to pull the delegation token from one of the sources. If Subject Identity is not known, but the accessed resource is known, then (1) can be used. In effect the discover of the Attribute Authority is keyed on the identity of the resource owner. Token can also be retrieved from (3). Finally, if the Subject Identity is known, pulling the token from (2) becomes possible.