Report - Guardian

268 The LSE Identity Project Report: June 2005Figure 4 - AuthenticationIn subsequent visits to a Government Service, Bob’s ID card simply authenticates to theService with respect to the identifier that has been associated with his user account atthat Service. To this end, Bob’s ID card generates a cryptographic proof-of-possessionof a private key that corresponds to the hooked-up identifier. This proof cannot beforged by anyone – generating a proof requires knowledge of the identifier’s private keyfor the identifier, which never leaves Bob’s ID card. The Service can locally verifyBob’s authenticity by cryptographically verifying the submitted proof; there is no needto consult any other party in order to verify Bob’s authenticity. In sum, Bob enjoys theconvenience of single sign-on at the various Government Services, while each of theGovernment Services can securely authenticate Bob within its own domain.The figures below illustrate three optional services that may be built on top of this basicprivacy-preserving ID card architecture without degrading the security, privacy, andautonomy of citizens and government service providers:- The first shows how the government could centrally collect non-repudiableaudit trails that are not privacy-invasive.- The second shows how government services could securely share accountinformation they hold on a citizen, even though they do not know that citizenunder a common identifier.- The third shows how a group of designated government services couldrevoke access to a citizen who commits abuse at any one service in thegroup, even though they do not know that citizen under a common identifier.