Interactive Consent

When the user is 'present', it's easy for for a provider to obtain their consent for the release of some piece of their identity being requested by another provider. For instance, if the browser is redirected from a Service Provider to an Identity Provider with a request for some slice of identity, the user is 'right there' for the IDP to pose the question 'You OK with this?' Or, if the identity is stored on the user's client, they are available to approve any identity requests.

If the user is once (or twice removed) from the provider trying to determine if the user is 'OK with this', things are trickier.

As an example, if a user SSOs into an online movie rental provider (MRP), the MRP might want to obtain the user's 'Favourite Genres' from other provider (FGP) in order to customize the selections they are displayed. The MRP can ask the FGP but, if the FGP needs clarification from the user before releasing the identity, they're all the way over at the MRP and so isn't available for interaction to clarify their wishes. What to do?

The Liberty Alliance ID-Web Services Framework defines a number of related mechanisms designed to address this issue:

1. Allow the FGP to respond to the MRP request and indicate 'Sorry, I need to talk to the user before I can give that out. Please direct their user agent to this address so I can get the clarification I need." After the user's browser is directed over to the FGP, they can be authenticated and asked for their consent to the release of identity. They can then be directed back to the MRP- which can then resend its original request for the user's preferred genres, this time with an expectation of success.
   
2. Allow the MRP to indicate within its request that it is willing to pose any consent requests the FGP might have back to the user. If the FGP does need to interact with the user, it sends the questions it has back to the MRP. As the MRP already has a session with the user, it can pose the question "FGP would like to know 'Are you OK with this?'". After the user answers, the MRP returns the approval (or not) back to the FGP as input to its authorization decision. As it is the MRP that is asking for the attributes in question, having them also attest that the user is 'OK with it' may not be appropriate in all situations.
3. Like #2 above, have the FGP send a request for interaction with the user , but to a dedicated Interaction Provider (IP) rather than the MRP itself. The IP, on receiving this request from the FGP, would use whatever channels it had available (e.g. SMS, email, IM, etc) to contact the user and pose the consent question. If the user approved, the IP would send that response back to the FGP, which would then process the original request from MRP appropriately (approve/deny).
   

This sort of mechanism within ID-WSF (and the focus on privacy-respecting consent that drove its development) often gets conveniently ignored when Liberty's architecture is pigeon-holed as 'enterprise only'.

Update: Pete comments:

Why is the obvious 4th option missing?

Send the user to FGP straight away, the FGP sends the user back with the request information, if the FGP requires something over the MRPs say so it has its interaction point right there.

Fundamentally, ID-WSF is a 'web service framework' and so the preferred channel for provider communication is a direct SOAP call rather than a browser-mediated front-channel. Justification includes:

1. the assumption that MRP will potentially be asking FGP for the list over and over (into the future) and so any efficiencies gained by using a front-channel redirect (in that consent can be obtained that first time) are outweighed by the advantages of using a direct call when consent needn't be obtained
2. A server to server web services protocol can be much richer from a functionality point of view as well as a security point of view.
3. related to the above, many of these messages are too big to reliably be handled via redirects and in many cases too big for browser-post
4. user experience and speed implications of the redirects
5. the limitations of the browser as a secure intermediary
6. the relevance of use cases where the user in question isn't even online, much less visiting the MRP

I guess a hybrid solution would have MRP use a front-channel the first time in order to faciliate FGP getting consent, and direct calls every other time. But, how would the MRP know what the FGP's (potentially constantly changing) consent requirements are in order to use the appropriate binding?