EP 1 499 940 B1 4  3  as a tax declaration using these receipts. Furthermore, long-termsolutions will integrate person- to-person appli- cations like calendar sharing, and business- to-business applications such as accessing services for which one’s employer has subscribed. [0009] Classicalsingle sign- on schemesand products contain a variety of login scripts or passwords for many applications. For example,US5,944,824disclosesasys- tem andmethodforsinglesign- on to a pluralityofnetwork elements. This does not allow browser-only clients un- lessbyusing aproxy (cf. Req. 2).Moreover, itonlycovers authentication information, not other identity-related in- formation (cf. Req. 3), and thus also no privacy policies (Req. 5). [0010] Classical public key infrastructures  (PKIs most notably as X509, essentially only consider authen- tication information (cf. Req. 3). As information is con- veyed via a fixed certificate, then if it does contain other identity related information, this information is fixed, con- tradicting Req. 5. For special-purpose client software, one can easily design a method to send other attributes separately, e.g., in attribute certificates, but this is not compatible with browser-only clients (Req. 2), and par- ticularly there is no interoperable method for using vary- ing browsers (also Req. 2). [0011] Classical products for transferringpersonalda- ta in e-commerce are form fillers. They interact deeply withbrowserstodrag- and-dropattributesintoform fields, or use powerfultools to interpret the fieldsinforms. They typically only work as complicated client software and else as proxies, contradicting Req. 2. Furthermore, they do not offer full interoperability, because there is no cor- responding method for the servers asking for the infor- mation. [0012] Microsoft’s Passport assumes one fixed loca- tion entity or at least only a set of entities that all have theinformationabout users in a certain domain, i.e., there is no choice by the user or based on other business re- lationships,e.g., choosingtheuser’sbankasthe location entity, contradicting Req. 1. [0013] This is an intrinsic property of this system, not something that can be changed by a different usage or embodiment, because the server is assumed to know a priori which location entity to connect to. While exten- sionstoa so- calledfederationareunder discussion, they are likely to have some of the other deficiencies remain- ing, like the following systems. Passport does not yet distinguish information that needs third-party confirma- tion(cf.Req.3).Furthermore,itallowsnorealanonymity: There is a global user identifier, which the user can only avoid by having multiple accounts and thus by difficult management, and furthermore the location entity learns the user’s communication partners (cf. Req. 4). There are also no flexible privacy policies (Req. 5). Further- more, Passport does not allow a direct contact between the server and the location entity, which is essential for safe transfer of longer data, and this is not trivial achieve in a federated context so that all the mentioned requirements are fulfilled. [0014] US 6,226,752 discloses a method and appara- tus for authenticating. It does not allow a user’s choice of the location entity for the same reasons as with Pass- port (cf. Req. 1). It only considers authentication infor- mation (cf. Req. 3) and thus no privacy policies (Req. 5) and no method for anonymity (Req. 4). [0015] Shibboleth  (http:// middleware.internet2.edu/ shibboleth),a project ofInternet2/MACE(Middleware Ar- chitecture Committee for Education), is developing ar- chitectures, frameworks, and technologies to support in- ter-institutional sharingof webresourcesthatare subject to accesscontrols. Shibbolethcontainsa methodfor find- ing the so-called university entity, and thus fulfills parts of Req. 1: The server asks the user for a user- friendly name of the university entity concerned and translates this using a further entity called WAYF that "knows the name and location of" each university entity. The redi- rection takesplace to thislocation only for authentication, and the university entity then redirects the user back to the server with a second address of the university entity. The server uses this other address to establish a direct contact to the university entity, over which it sends a re- quest and gets a response. This protocol does not allow local wallets (Req. 1) together with anonymity (Req. 4), in particular because the second address identifies the place of the university entity which, for local wallets, is theplace of theuser. Thereisno knownmethod to make this address relative, i.e. saying only "on my machine". The first address can also not be intended to be relative because the knowledge of all names and locations of localwalletswould defeat the purpose.Yet another point incompatible with the combination of local wallets and anonymity is that all "assertions" in Shibboleth, i.e., the identityrelatedinformation sent,mustcontainthe domain name ofthe universityentity. Furthermore, while Shibbo- leth includes privacy policies, it is not as flexible as de- sired (cf. Req. 5), because requests do not include pri- vacy promises by the server. Finally, for requests where the release of the information is not pre- authorized by the user to the university entity, Shibboleth has an inef- ficient flow, because the browser focus(i.e., awayto ask the user) must be reestablished by a further redirect, fol- lowed by yet another redirect to the server. [0016] The document"BindingandProfilesfor the OA- SIS Security Assertion Markup Language (SAML)", www.oasis-open.org  (Online)  15  February  (2002-02-15), XP002271983 discloses asystemin which a user who wants to access a target resource available from a destination side authenticates herself to a source site und uses then a secured resource at the destination site withoutdirectlyauthenticating tothe destinationsite. [0017] From the above follows that there is still a need in the art for an improved identity management system including the exchange protocols between persons and organizations. 3