Fig-28: Invitation phase
Consider Figs 28 and 29 and the depicted steps as follows:
Fig-28: Invitation phase
Delegator (Bob) selects the resource to share at the Service Provider. Service Provider knows who Delegator is as Bob used Single Sign-On to login to the SP.
Once a resource has been selected, Delegator is transferred to the user interface of the Delegation Service. The Delegation Service generates an Invitation Ticket, which is formatted as URL pointing back to the Web GUI of the Delegation Service, but with a nonce component that is hard to guess. The invitation is remembered in the database of the Delegation Service.
The Delegator then gives the invitation to Delegatee. The Delegator does not need to know the specific identity of the Delegatee in the network. However, if the Delegator cares, he could use out of band means of ascertaining that the Delegatee that receives the invitation is the person to whom he wishes to delegate, e.g. instead of emailing the invitation, deliver it personally.
The Delegatee now resolves the invitation by clicking the URL and lands at the Web GUI of the Delegation Service, which asks the Delegatee to identify itself by means of an IdP (usually Single Sign-On). This IdP can be different from Delegator's IdP as long as the Delegation Service and the SP are willing to trust it. Various mechanisms, that are described in Sections 3.7 and 3.6, to establish the trust exist.
If Delegatee does not have any IdP, then Delegatee should register with some IdP, otherwise he can not continue the flow.
N.B. A flow is possible where the invitation itself grants access to the resource without any need to authenticate the delegatee. While this flow may be interesting in some commercial settings, it lacks sufficient audit and accountability safe guards to be included in the TAS3 architecture.
Delegation Service invokes Delegatee's Identity Mapping Service to convert the identity of the delegatee are the Delegation Service to the identity of the Delegatee at the SP and stores it in the invitation database. The identity will be encrypted so that only SP can open it.
The Delegation Service generates an artifact with nonce properties and associates it with the invitation. It then redirects the Delegatee to the user interface of the SP, passing the artifact in the query string.
SP dereferences the artifact by contacting on back channel the Delegation Service, which looks up the invitation using the artifact and generates a Delegation Token binding together the authorized resource (known from time when invitation was created) and the Delegatee (known from step 5); signs the token, and ships it to the SP.
The SP PEP now passes the invoking identity, i.e. the Delegatee, known from Single Sign-On and the (contents of) Delegation Token to the PDP, which will authorize the operation. Typically the authorization rule will require that the accessed resource and invocation identity match the Delegation Token.
Fig-29: Accept invitation phase
In this flow, the Delegation Service and the SP could be merged, effectively optimizing steps 2 and 7 to function calls. While such merge is technically sound, it may hinder development of competitive market for the delegated services. The flows in [TAS3D42Repo] Appendix 2 "Proof of Ownership Using Permanent IDs" essentially presents the invitation flow where the invitation is then embedded in a composite document. That Appendix does not show how the Proof of Ownership URL (PoOURL) is dereferenced. Essentially the steps 4-8 could be performed, or other means to authorize the access could be used. It is important to understand that reliance on mere invitation does not leave audit trail trace about who accessed. The delegatee really needs to be identified (e.g. by SSO to Delegation Service) for the audit trail to be useful.
Essentially the steps 4-8, above, could be performed, or other means to authorize the access could be used. It is important to understand that reliance on mere invitation tokens (secret URLs) does not provide identity information to the audit trail about who accessed the document. But if authentication and authorisation of the PII recipient took place because a fixed proof public URL was used, then full audit information is provided.