16  15  EP 1 499 940 B1 mation is sensitive and which not. The user 20 has full flexibility to edit or delete the given attribute values and to add missing attribute values. Optionally, the user 20 gets an indication on what is necessary to submit or con- firm by a hint like "*". That means the presentation addi- tionally includes elements that characterize attributes as mandatory or voluntary from the point of view of the re- ceiving entity 50. The meaning of the user interface ele- ments and indicators is explained, in our example in the lines starting with "Red:" and "*:" The "Submit" button allows the submission of the information in the form. In a further example, aniterationof sub-stepsIVd.iiito IVd.v can be performed where the attributes are presented in the repetitions of the sub-step IVd.iii with additional an- notations by the location entity 40, e.g., error messages, andthe response to the requesting entity 50isonlymade after the last iteration of the release in sub- step IVd.v. The presentation can be executed as a normal web form witheditable fields for the attributes. Inanotherexample, none of the attributes are released if not all mandatory attributes are available and authorized after the editing phase with the user 20 or a suitable iteration of the steps withthe specificannotation that mandatory attributesare missing. [0055] Fig. 8 shows a schematic illustration of an ex- tension ofthefirst or thirdembodiment providing authen- ticity of the browser 30 in sub- step IVg. In view of the location entity 40 the acquiring step IV is here referred to as the transfer step IV. Fig. 8 already starts with the second part of the redirecting step III where the client application 30 connects to the location entity 40 in sub- step IIIb. The contact step IVa is performed in that the locationentity40contactstherequesting entity 50. Then, the request step IVc is performed in that the requesting entity 50 requests the identity- related information IRI from the location entity 40. In sub-step IVd random value k is generated by the location entity 40. The re- sponse together with the random value k is sent to the requesting entity 50 in response step IVe. Sub- step IVf.ii indicates the transmission of the return address from the requesting entity 50 to the location entity 40. Then, the redirect is performed as indicated by the sub-step IVg. Therein the return address with random value k is trans- mitted in sub-step IVg.i from the location entity 40 to the client application 30, which is further connected to the return address, i.e. to the requesting entity 50 which re- ceives the random value k, as indicated in the connect back step IVg.ii. In sub- step IVh the requesting entity 50 uses the received random valuek tolookupthe response received in the response step IVe where the same ran- dom value k occurred. Application-dependent interac- tions, initiated by the requesting entity 50, between the clientapplication30 andthe requesting entity50 are then performable again, as shown in step V. By sending the random value k to the client application 30, the client application 30 is enabled to prove its authenticity with respect to the identity-related information IRI to the re- questingentity 50. In another example,thevalue kis only pseudo-random, or even only partially pseudo-random. However, it should be practically unguessable in all cor- rect examples. [0056] Fig. 9 shows a schematic illustration of an ex- tension of the communication environment as described with reference to Fig. 1. A second location entity 42 is arrangedadditionallyto Fig.1.Thesecondlocation entity 42 can be local or remote and is connectable to the client application 30 and the request entity 50 via the commu- nication lines 5. Generally, one client application 30, i.e. one browser 30, interacts here with several location en- tities 40, 42, and selects an appropriate one in the loca- tion-request step II. [0057] Fig. 10 shows a schematicillustrationof another arrangement of the communication environment as de- scribed with reference to Fig. 1 or Fig. 9. The identity- related information IRI is here provided by one further location entity, i.e. the second location entity 42. The identity-related information IRI is obtainable by the re- questing entity 50 via the location entity 40, hereafter also referred to as first location entity 40. The location information LI of the second location entity 42 is hence stored on the first location entity 40, together with indi- cations what identity-related information IRI the second location entity 42 holds. Thus the client application 30 can always select one first location entity 40 in the loca- tion-request step II. The example shows the second lo- cation entity 42 only connected to the first location entity 40,indication an embodiment where the first location en- tity 40 retrieves the identity-relation information IRI di- rectly from the second location entity 42 within the sub- step IVd. The identity relation may carry authentication or othersecurityattributesfromthe secondlocationentity 42. In another example, the first location entity 40 can redirect the client application 30 to the second location entity 42 within sub-step IVd to also allow the second location entity 42 interaction with the user 20. In a further example,the second locationentity42 may forward con- tact information of the requesting entity 50 to the second location entity 42 so that the second location entity 42 can transfer its identity- relationinformation IRI directlyto the requesting entity 50. [0058] All examples as shown in the figures assumed that the requesting entity 50 and the location entity 40 (or 42) can directly authenticate each other. This can easily be achieved with knowntechniques,e.g., byusing public-key certificates with a common set of root author- ities agreed upon in the respective federation. For in- stance,the requestingentity 50mayusea securesocket layer (SSL) server certificate to authenticate to the loca- tion entity 40 in the contact step IVa, if the connection is via HTTPS or another protocol using TCP (Transmission Control Protocol). To enable anonymity, the location en- tity 40 should not always use such a certificate, e.g., if only freely choosable identity-related information IRI is requested. If identity-related information IRI needs con- firmation by a known authority (which may be the first location entity 40 or second location entity 42 in Fig. 10), 9