Identification is the basis for trusted relationships in business as well as in administration. In Europe Member States have developed rules and methods how citizen and businesses are identified electronically. Cross-border applications still suffer from the fact that these methods differ from the legal, from the organisational but also from the technical point of view. Federated and interoperable identity management can contribute to a seamless way of offering electronic services. Taking into consideration that such cross-border services need to fit into the existing structure models and structures of interoperability are discussed with a special focus on the needs of government applications. The essence of eID when talking to governments With physical presence we have a log tradition in giving evidence of the identity. In general “identity documents” are used. These documents contain information about the subject that allows a sufficiently secure link to the actual person plus methods that should prevent from tampering with the document. In the general case these documents are issued by an authority. In the electronic world we see a slight shift. As technology for electronic identity documents was not available until recently we did see a shift from identity documents to other means with electronic services. Usually the resulting method binds to a purpose in this case. E.g., when identifying at an electronic shop it is obviously sufficient if someone presents a credit card to pay. As the service is in the same dimension as the identification (the value is in both cases money) abuse is unlikely. Therefore it is possible to use low security and even work with userid and password. As we see with electronic banking the picture and risk changes totally when application switches from the type “shop” to “access”. With administration “values” are not monetary values and thus identification becomes a key issue. A further fact is that - unlike with business - it is not the choice of the citizen to get in contact with administration. Both facts have influence on the security demands but also on the privacy demands an eID system has to meet. In practical applications we see different security levels. However, from a legal point of view there is in most cases little justification for the introduction of security levels. This 141 issue is not transparent as long as we operate within one administration since the application still will map their security demands into the user interface. However as we walk cross domain this absence of justification to differentiate between security demands becomes a real issue. This fact becomes even more complicated as we do not have the same structure of administrative processes in different administrative domains. Unless there are extensive bilateral agreements we might end up in a situation where we have only two states “identified” “non-identified”. Since we still want to offer basically all administrative procedures identification will need quality. The key players With the use of eID we identify the user - the subject to be identified and the service the user desires to access. As long as we do not introduce further roles the service would have to take care of the registration, the pairing process between the user's identity a and the security presentation that might range from userid/password to card/pin as needed, the management that consists of revocation, lost token/ forgotten password management, and the handling of the security presentation. This setup forms a closed circle and all other services would have to offer the same elements and perform the same procedures. If the same security presentations are foreseen, one would also need a compatible security policy at all services concerned. Interoperability and eID federation has the following main goals: Reduce cost both on the service and on the user side. Registration and management are high cost services. Still both have a very low frequency. Enhance comfort as the ideal situation would only need one security presentation. Offer enhanced services like single sign on etc. To benefit from these advantages a set of further services and elements need to be defined and added to the simple model described above. Each service has implicitly or explicitly an application oriented “identifier” of each of its users. To enable synergies of eID registration and eID management some sort of implicit or explicit mapping of these sets of “identifiers” must exist to avoid the need of multiple registration. These identifiers and the policy of mapping and handling will greatly define the data protection capabilities of an eID system. Generally we can see three classes: disjoint: no direct interoperability of eID is possible. One still could share security devices and mechanisms etc. but registration and management would need duplication or escort mechanisms. (France would be an example) flat: a centrally managed identifier that is is used throughout. This raises many privacy concerns that can usually only be kept under control by restrictions of use of the identifier. (Italy, Sweden, and Belgium are examples) derived: through a security mechanism, that can be a central service or a 142 cryptographic mechanism systematic mapping is performed in a way that does not allow cross-relating identifiers (New Zealand, Denmark, and Austria are examples) When implementing interoperability and federation care has to be taken not to break the given protection principles when crossing the border. This is of high importance as crossing the border twice would result in the same breach within the country. A first additional service with the implementation of interoperability was identified as the register of identifiers. Given these registers of identifiers and given a mapping service among these registers back office interoperability can be implemented. Back office interoperability and access interoperability has to be clearly distinguished. As we have seen data protection is key with back office interoperation. Technology on the other hand is in the foreground when it comes to access interoperability. The combination of the methods used with these two elements will define the interoperability model. As we see different schemata with different registers of identifiers we need a further service that translates from one schema into another. This identifier translation service needs a high degree of trust as it interfaces with both schemata the source and the destination schema of identifiers. It will be the key question who can operate such translation and also where can such translation be executed. As we hardly see identifier schemes without restrictions of use there must be adequate control by the owner of the identifier over the execution of the identifier translation. If for example the user is deemed to be the owner of the identifier the translation must be under his control. This is also an aspect that will influence applicability of specific interoperability models. APPLICATION eID eID DATABASE APPLICATION $f(eID A)$ eID B eID eID DATABASE Having in place back office interoperability access interoperability can be implemented. Assuming that access methods are in place that perform authentication of users at a specific point in time and associate an application identifier so that the specific service can be accessed we still need interfaces that allow other technologies coming from other identification domains to perform their security presentations. This results in a further 143 service that translates security presentations. This security presentation translation service needs special focus. It occurs directly or indirectly at any service and we cannot assume that we have all services well organised in layered structures. Still security presentation might range from userid and password, client certificates, one time SMS codes to electronic signatures. Viewing effort and cost the major part will be in this last service. Standards and practices offer models for this task SAML [SAML], OpenID [OpenID], CardSpace [CardSpace] etc. have to be mentioned here. The goals of interoperability The first goal would be just to provide identified access. This however is not sufficient. Implementations of eID usually include a series of assumptions and many of them are implicit. It will therefore be necessary not only to map identifiers but also to have a transparent knowledge of the nature of this mapping and keeping this with the target identifier. The following example should make this more transparent. With the Austrian eGovernment law [E-GovG] a regulation is in place that focuses inclusion in a way that for people not able or not willing to personally use eID and eGovernment a civil servant can automatically acquire a mandate so that this civil servant can act on behalf of the applicant. While this regulation affects eID and mandates which form an essential part of eID when this person acts towards an Austrian government agency, it is neither applicable to non Austrian agencies nor to companies. This clearly shows that the acting on behalf example and the country of origin must be in the security assertion for eID and must be transparent to the application.[EGOV ABC] A further goal is to allow inheritance of identification properties. The above example shows one instance where this is key. However there are many more examples like e.g. the identification quality (e.g. qualified certificate). Finally an important goal is to provide inheritance of security and data protection properties. Without such inheritance it would be impossible to implement legally accepted eIDM systems. Models of interoperability The choice of models is driven by the legal and organisational environment. Applicability and legality might restrict to a large extent. To provide specific examples a userid / password schema could be mentioned. In such schema a model with central verification might be the only way to manage. Any model that counts on the user's workstation and decentralised operation cannot be used. However, as it comes to data protection such central exchange might be unacceptable as it holds all details about identifications. 144 In general we see two models for eID interoperability: