14  13  EP 1 499 940 B1 255 bytes. By obtaining a connection message in sub- step IIIb, the location entity 40 is instructed to transfer theidentity-relatedinformationIRI to therequesting entity 50. In the acquiring step IV the requesting entity 50 ob- tains the identity- related information IRI as follows. In the contact step IVa, the location entity 40 is connected to the contact address, i.e. the requesting entity 50, using the protocol contained in the contact address unless it proceeds as described with reference to Fig. 3. The re- quest step IVcisperformedwherein the requesting entity 50 requests the identity-related information IRI from the locationentity 40 over the connectionsetup inthecontact step IVa, retrieving the appropriate request according to the session identifier SID. The request may be in any known form, e.g., an agreed- upon Extensible Markup Language (XML) schema. The requesting entity 50 re- ceives in the response step IVe the identity- relatedinfor- mation IRI from the location entity 40. The response will be in a known form corresponding to that of the request, e.g., from a corresponding response XML schema. The location entity 40 can decide on whether to respond at all and what, e.g., by evaluating user authentication, pol- icies,authentication and credentialssubmittedbythere- questing entity 50 with the request, real-time release by the user 20, or the like, as indicated by sub- step IVd. Sub-step IVf.i indicates that the return address may de- pend on the received response, e.g., different personal- ized versions of an originally requested resource. The return address is then sent by the requesting entity 50 to the location entity 40, as indicated with sub- step IVf.ii. Then, the redirect is performed as indicated by the sub- stepIVg.Therein the return addressistransmittedinsub- step IVg.i from the location entity 40 to the client appli- cation 30, which is further connected to the return ad- dress, i.e. to the requesting entity 50, as indicated in the connect back step IVg.ii. This step may carry additional information, e.g., for authenticating the browser 30 as explained below with reference to Fig. 6. Sub-step IVh allows the requesting entity 50 to look up the appropriate response received in the response step IVe for the con- necting browser 30 in any known way, and thus to use the response in further interactions with this browser 30. Theuse ofHTTPS providessecure sessionsfor this, they may be augmentedbyother known session maintenance mechanisms. Browsing, executed by user 20, between the browser 30 and the requesting entity 50 is then per- formable again, as shown in step V. [0052] Fig. 5showsan illustrationof aformorexample screen to be presented to a potential user with a location query as presentable in the location- request step II in Fig.4. To make itrealistic,a refusalto identifyand legacy authentication by user name and password are als shown, as well as links to information about the request- ingentity50, e.g., an organization, which information may help the user 20 to decide what to fill in. The "o"s are radio buttons, the fields are for entering text. The words "federated identity" can stand for a brand name to be chosen. Selecting "my own wallet" gives a redirect to "lo- calhost", i.e. the location entity 40 which is on local. In- puttinga "wallet holder"redirectsto the location orserver addressof aremote locationentity 40. Thelookupchoice leads the requesting entity 50 to look for the name en- tered after "my name is" in a global directory; this option decreases privacy but some people might forget their locationentity’s address. The user 20 can inform himself about the requesting entity 50 under "who we are" and about the policies under "privacy policy". With the "Sub- mit" button the information can be submitted. As de- scribed with reference to Fig. 4, there are several ways to allowuserstoavoid sucha screen if theyalwaysallow their location entity 40 to be contacted. [0053] Fig. 6 shows a schematic illustration of an ex- tension of the third embodiment as shown in Fig. 4, in particular an embodiment of sub- step IVd, the derivation of a response. Only the relevant flows are depicted. In sub-step IIIb the browser 30 connects to the location en- tity 40. In the acquiring step IV the requesting entity 50 obtains the identity-related information IRI. Therein, in sub-step IVd.i an authentication of the person is per- formed. Thissub- step IVd.ican also be performed inpar- allel when the contact step IVa and the request step IVc are executed. It may be omitted if a secure session ac- cording to a known mechanism is in place. Then a half- finished form is presented to the user 20 in sub- step IVd.iii. A sub-step IVd.ii indicates the preparation of the responseasfar aspossible while using a predefined pol- icy, and the transformation from the request- response format to a user-friendly form. The user 20 can adapt the form in sub-step IVd.iv before the finished response as formis transmitted in the release sub- stepIVd.v fromthe browser 30 tothe locationentity 40 which finallyforwards it, now again in the request-response format, to the re- questing entity 50 in the response step IVe. [0054] Fig. 7 shows an illustration of a half- finished form as to be presented to the user 20 in sub- step IVd.iii in Fig. 6. The initial text explains the form and specifies who asks for this information, i.e., <name> is the name of the requesting entity 50, as obtained by the location entity 40 in the authentication of the requesting entity 50 duringthe contact stepIVa.If no suchauthentication pre- cedestheresponse step IVe in another embodiment, this line in such a form should be formulated differently ac- cordingly, e.g., the user 20 should be asked to check the server certificate in the HTTPS connection from step I. The "Name", "Shipping address", "National ID number", and"Your income"are examplesofattributesor attribute names. Their respective attribute values are already en- tered for the "Name", "Shipping address", and "National ID number", because these are assumed to be known to the location entity 40 in this example. "Your income" is not known to the location entity 40 and therefore empty. Among the known attributes, "Name" and "Shipping" ad- dress are assumed to be pre-authorized, while "National ID number" is not. Therefore their attribute values are presented in different user-interface styles, e.g. in differ- ent colors, so that the user 20 sees easily which infor- 8