Fig-19: Flow of front channel call that makes a call on back channel.
This flow expands on front channel by adding one web services call on back channel. This section addresses Req. D1.2-3.10-JITPerm.
Fig-19: Flow of front channel call that makes a call on back channel.
Example: In our concrete example U authenticates and makes a service
request to A which invokes another service provider B which also
contains information about user U.
Assumptions:
There is service provider IdMapper (IM). Each user usually has one IM that knows the permanent userIDs at the different service providers.
IdPs know the IMs of the users (there are several ways to know. See section on user registration in this document to be written.)
IdP/IM produce IM tokens. The IM tokens include the following information (which means this information is known to the IdP s and IMs):
IM address
the permanent pseudonymous userID of the user at the IM
which service provider can use the token
how many times and how long the token can be used (some of that could be pushed to a PDP attached to the IM, except the constraint about who can use it)
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). (Req. D1.2-3.10-JITPerm)
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.
If B needs to invoke further services with a service provider C it communicates with the IM of U using its TokenIM and repeats the steps 4 through 6. See the recursive case, below.
B returns a result to A which completes the service and returns result to user U.
If a User has multiple IMs, multiple IM tokens would be generated if there was no way to ask User's choice or other deciding rule to pick just one. This may result in practise nearly all IMs being aware of each other, but this need not always be the case and even partially populated IM matrix would remain useful to the user. Further, the IM matrix may be different for different users.