This section addresses Req. D1.2-7.1-Deleg.
If the SP above needs to subcontract one or more tasks to a backend service, and that backend service is to act from an authorization perspective as if the user herself had contacted it directly, then the backend service will need to be given the user's authorization attributes. The exact model for how this is to be done is for further study in the following years of the project. Whilst there have been many previous models for dynamic delegation of authority none of them to the best of our knowledge have supported attribute based delegation simultaneously with privacy protection of the delegator's and delegate's identities. The following models at least are suitable for further study:
Trusted SP. The first SP simply forwards the initial authentication statement and referrals from the authenticating IdP to the backend SP, and the backend SP follows exactly the same process as the first SP (described above). (Note that the attribute statements cannot be forwarded as these were targeted specifically for the first SP and encrypted to it.) The disadvantages of this method are:
the backend service must trust that the first SP is authorised to forward the user's authentication statement to it. Otherwise a rogue SP could illegally forward the authentication statement to a backend SP in order to defraud the user;
the user either has to know beforehand which backend services are going to be contacted, so that she can proactively sets up specific Link Release Policies for these backend SPs, or if she does not know or is unaware that backend services are to be involved, she has to set up a default policy for All Other Services (as described in Section ?tas3arch-GeneralizedUseCases-UsingLinkingService?). Otherwise the backend SP is likely to deny access to the subcontracted task.
Direct Delegation. The user contacts a delegation service and delegates her attributes to the first SP, bestowing these credentials with delegation rights. The first SP uses these credentials to authorize the user, and then delegates them further to the backend SP, optionally bestowing further delegation rights on the backend SP in case it needs to subcontract further. The advantage of this model is that the backend SP does not need to trust the first SP as much, since the latter has specifically been delegated rights to it by the user. Further research is still needed here, since it is currently not known precisely how to delegate an aggregated set of attributes issued by multiple attribute authorities when the user is known by different identifiers at each authority. We will need to find a way to combine the linking and delegation services to work together in a trustworthy manner.
FileSpace. We use a completely different model for multiple credential authorisation, termed FileSpace [Chadwick09]. This gives the user a set of files which he can copy freely between devices and service providers. Service providers can also freely copy the files between each other to delegate authority on behalf of the user. The files are actually encrypted authorization credentials signed by their respective attribute authorities. Consequently they are useless to the recipient (who can be a thief or a genuine SP) until it gets the decryption key. Herein lies the twist. The user is the only person with the private key that can decrypt them. Thus before any front end or backend SP can utilise the credentials they must ask the user for the decryption key. Once they have the decryption key they know that (a) the user is the genuine owner of the credentials as she was able to decrypt them, (b) the attributes genuinely belong to the user because they are signed by a trusted attribute authority, and (c) the user has given consent for them to be used (because she provided the decryption key). If we place the user's private key in the Dashboard, then each SP that wants to authorize the user must first contact the Dashboard asking for a decryption key and the user can keep track of progress of his task as various events arrive at the Dashboard. She can then give consent (or not) as appropriate.
Shibboleth Portal. The Shibboleth community has developed a delegation model, initially targeted at web portals and portlets, but generalized so that it can be used for any web services based delegation. It is based on the Liberty Alliance ID-WSF Enhanced Client or Proxy SSO Profile [SOAPAuthn2] instead of the SAML 2.0 Web Browser SSO Profile [SAML2prof] which Shibboleth currently uses for SSO. It works by the first SP going back to the user's IdP to authenticate itself and ask for a new authentication statement allowing it to become a delegate of the user and a delegator to a backend SP. The user's initial authentication exchange with the IdP is enhanced to allow the user to specifically authorize delegation by the SP it is contacting. This causes the IdP to insert a new token into the authentication statement which authorizes the recipient (the SP) to call it back to become a delegate. After the SP has authenticated and authorized the user, the SP contacts a backend SP and quite naturally is required to authenticate to the latter, as is any user. So the SP then contacts the IdP, authenticates to it (say by using mutual TLS) and passes the token from the user's authentication statement. This notifies the IdP that the SP is entitled to act as a delegate of the user, so it issues an authentication statement in the name of the original user, to the SP. This statement is targeted at the backend SP, and again contains a token that allows the backend SP to call it back to become a delegate of the user in future. The first SP passes the authentication statement to the backend SP and thereby masquerades as the user.
Subcontracting. Of course the first SP can always subcontract the backend SP to perform the task on its own behalf (as is typically done in manufacturing supply chains today), in which case the user's attributes are not needed by any backend service.