Fig-22: Flow of recursive calls on back channel.
Fig-22: Flow of recursive calls on back channel.
The Steps of the Protocol with one layer of Service Provider Invocations
(Same as above.) User U wants to access service provider A and starts interaction with A.
(Same as above.) U is redirected to IdP1 (n.b. IdP discovery is not addressed in this flow, though industry standards like [SAML2core] and [CardSpace] do address it)
(Same as above.) U logs in at IdP1. The authentication method is out-of-scope for this flow.
IdP1 returns two encrypted tokens to A:
the token contains U's permanent pseudonymous userID 123A4. It is encrypted such that only A can read it and authenticate the user.
the token is encrypted for the IM and contains the permanent pseudonymous userID of U with IM which is 789IM. The token is bound to A (contains an indication that only A can use it towards IM).
A authenticates U with TokenAuthn (possibly Single Sign-On - SSO).
A needs to use other service provider B to complete the services and needs the permanent pseudonymous userID for U in B. For this A passes TokenIM from IdP1 to IM.
The service provider B is selected based on Trust and Privacy Negotiator's efforts to find a suitably trusted SP from the database maintained by the IM (or some other part of the Discovery functionality).
IM decrypts TokenIM from IdP1 and sees the user U registered as 789IM in its database. This with the token serves to authenticate the user to IM. Provided that the expiration time of the token is relatively short, the user can be assumed to be present (User Present scenario).
B looks up the userID of 789IM for service provider B which is 456B (the lookup values can be in encrypted form).
IM encrypts two new tokens for the invoked service providers B and gives them to A.
the token is encrypted for B. The token contains the pseudonymous identity of user U at B. In this case it is: 456B.
the token is encrypted for the IM and contains the userID of U with IM which is 789IM The token is bound to B.
A sends a request to B for a service for U and sends the two tokens from the IM.
B decrypts the token and recognizes the user as having UserID 456B in its database.
B sees that 456B is the user U . It calls the authorization function to see if U is authorized. Assuming the answer is granted, the service is provided.
In course of providing the service, B wishes to call C. This is termed "recursive call" and such pattern can occur to any depth. B starts by discovering service of type "Role Authority", sending the IM token to the Identity Mapper.
The Identity Mapper decrypts the IM token and recovers the pseudonymous persistent ID 789IM, which is then used to locate from the database of IM the pseudonym of the User at service C, which is the only service of type "Role Authority" registered for the User. Identity Mapper returns two tokens: (i) the pseudonym of user at C encrypted such that only C can open it ("E(fgh)C" in figure), and (ii) IM token that C may use to make further web services calls.
B calls C, passing the tokens along.
C decrypts the token "E(fgh)C" and recovers the persistent pseudonym "fgh". It uses this key to look up the role from the database and returns it to B.
B uses the role to authorize the request (6) and returns a result to A which completes the service and returns result to user U.
Steps 7 through 10 can be repeated any number of times in a recursive
fashion.