One of the experiences that was gathered was that the inclusion of the user is not only desired in many cases but also compulsory. In many cases one must interact with the customer – whether it is about formally necessary agreements to ‘General Terms and Conditions’ or about data protection legal aspects. Even the user interface can become a challenge thereby. A Windows-Interface is shown for Microsoft CardSpace; for other approaches one must carry out an authentication at the Identity provider. Since an Identity Provider often works for many Service Providers, new challenges arise here.
That business procedures and business models change is still a great challenge for corporations. Thus for example, the relation between a large internet Service Provider and the corporations offering service on their portals are clearly evident. If it “only” acts as Identity Provider, whose services are also subsequently used by different Service Providers outside of the portal, it is clearly more difficult for all participants to define meaningful business models.
The most exciting challenge is surely the question of liability. It becomes particularly clear when one thinks about the Claims model that Kim Cameron from Microsoft suggested. There is a question of trust – also contractually confirmed in the classic model of authentication in practice between different business partners, on which basis the Service Provider can rely on the correct authentication through Identity Provider. In the Claims model, „doubting” of this claim plays an important role. Claims will be presented and checked by the Service Provider and recognized – or not. The consequence is that the responsibility also shifts, even up to the Service Provider. The fact that this change has much greater effects than the technical changes is out of question.
But there are usually challenges with liability. An Identity Provider must develop a business model that covers its liability risks. This becomes above all meaningful in which an ISP operates as Identity Provider and builds up businesses of diverse importance. The risk is limited for simple interaction but it is shown much more differently with greater business transactions. The business models and how they handle and organize such risks must be examined here also.
Thus federation remains exciting. The most important advice which can be offered is that one concentrates and analyses whether the business processes, business models and liability claims function for Federation-projects with approaches of user-centric Identity on the Business Gate in the first place. It is only then meaningful to think about growing technical designing possibilities. There are even challenges here – like for example, the missing roaming-support for Information Cards.
The situation is made clearer simply through use of Federation-approaches within the corporation or by bi-directional B2B-approaches (the Federation between two business partners). There is more experience here. In addition, it is first necessary to define the frame for the Federation correctly before implementation.