3.3 Delegation

This section addresses Reqs. D1.2-3.7-Deleg and D1.2-7.1-Deleg.

It should be noted that some system entities may be modelled as juridical persons and can, thus, participate in Delegation like the Users can.

General properties of delegation are

• Express and auditable act of creation (e.g. issue power of attorney), with indication of registration (where needed).

  • Specification of delegatee ("Performer" of a web service action)

  • Specification of delegator (sometimes, if a resource of the delegator is involved, "Target" of a web service action)

  • Specification of scope

    • Actions and/or

    • Resources

    • Role based delegation

  • Specification of expiry and other policy constraints

• Sub-delegation, when this ability is expressly mentioned in constraints

• Ability to revoke, with extent to with delegation is possible, such as

  • At any step of sub-delegation chain

  • Any superior anchestor can revoke any descendant

  • Audit

• Divulgation of issuer's signing private key MUST NOT be used as a mechanism of delegation.

• Expression of the delegation and target in web services calls at any level of recursion

• Verification by Relying Party: mandate assurance & authenticity (typically verify sig on token + query of MA for revocation info + evaluation of possible constraints)

• Transparency: ability for user to verify which mandates have in fact been exercised or formally accepted.

  This could be implemented by the Delegation Service feeding information about each invitation usage to the Audit Event Bus, where the Dashboard can pick up the information and display it to the user when user comes to consult it. Also, when Service Responder, or its CVS or PDP, consumes a delegation token, it will inform the Audit Event Bus so that the Dashboard can have the big picture of the delegation usage.

Delegation is also discussed in section 6 "The Delegation Service" of [TAS3D42Repo] and in section 6 of Deliverable D7.1 [TAS3D71IdMAnAz].

*** work from Kent 2010

Designation of Delegatee may be by

• Delegation to anyone (or first one) possessing an invitation token

• Delegation to someone specific

  • How is the someone identified? Well known unique ID is an option.

• Delegation to anyone having specific role

• Delegation to anyone having some relationship to the Delegator

• Delegation to anyone having some relationship to previous tasks, business process steps, or environmental context (e.g. physical access).

Steps of delegation

1. Identify delegate

2. OPTIONAL: Resolve invitation to delegatee (may involve additional authorization)

3. Authorize delegation, e.g. to check for separation of duties

4. Implement delegation, e.g.

   • Generate target identity token

   • Set up Az rules (consider special case)

   • Assign roles

   • Create relationship, such ownership (e.g. assign owner)

5. Terminate delegation

Use case 1 "Headhunter"

Headhunter Alice processes matching requests from customer. Each headhunter has assigned to it some customers and usually he would not handle requests from other customers. However, the headhunter can assign one of his cases to a colleague, Bob. In this case the colleague is able to process the request despite customer not being his. However, it may turn out that a headhunter Alice is sick and requests from his customers pile up. In this case the manager Charles is able to assign the tasks to other headhunters, such as David, without any intervention of the headhunter that owns the customer, Alice.

Use case 2 "Job seeker and a coach"

Job seeker arrives and starts job search. In the process job seeker needs help of a coach. A coach needs to be assigned. This can happen in many ways: use same coach job seeker has previously used, pick coach that is face to face with the job seeker, pick first coach that grabs the task, or assign any assigned and known coach.