thersteps orsub- steps are indicatedby Roman numbers in a circle. The flow is understood as being performed sequentially from top to bottom as indicated by the in- creasing Roman numbers. In step I application-depend- ent interactions are performed between the client appli- cation 30 and the requesting entity 50. In a location-re- quest step II, which is initiated by the requesting entity 50 (sub-step IIa), the requesting entity 50 requests from the client application a location information LI that corre- sponds to the location entity 40 that possesses the iden- tity-related information IRI. The location information LI is sent to therequestingentity 50in sub-step IIc. Optionally, sub-step IIb allows the client application 30 to derive the location information LI in different ways, for example, by asking the user 20 or internally. It follows a redirecting step III with a redirect instruction (sub-step IIIa) wherein after all the client application 30 is connected to the lo- cation entity 40 (sub-step IIIb). By doing so the location entity 40 is instructed to transfer the identity-related in- formation IRI to the requesting entity 50. In the acquiring step IV the requesting entity 50 obtains the identity-re- lated information IRI as follows. A contact step IVa is performed wherein the location entity 40 contacts the re- questing entity 50. Then, a request step IVc is performed wherein the requesting entity 50 requests the identity- relatedinformation IRI fromthe locationentity40. Finally, the requesting entity 50 receives in a response step IVe theidentity-related information IRIfromthe locationentity 40.Therequest can be retrieved in different known ways, as indicated by sub-step IVb, e.g., by a session identifier that the requesting entity 50 includes in the redirecting step III and the location entity 40 includes in the contact step IVa. Moreover, the location entity 40 can decide on whether to respond at all and what, e.g., by user authen- tication,policies, orthe like, asindicatedbysub- step IVd. The response can be prepared using internal and possi- bly externalinformation.Sub- stepIVf indicates a possible repetition of the request and response steps IVc and IVe to get more identity-related information IRI, or to resolve errors, and a possible end-message for this exchange. As indicated by the sub-step IVg, a redirect from the lo- cation entity 40 (redirect back step IVg.i) via the client application 30 to the requesting entity 50 in a connect back step IVg.ii can be performed. Application-depend- entinteractionsbetweentheclientapplication 30and the requesting entity50 are then possible again,asindicated with step V. 

[0050] Fig.3 shows aschematic illustrationofasecond embodiment with a similar message flow compared to the first embodiment with the difference in that the ac- quiring step IV is performed without the contact, request, andresponsestepsIVa,IVc,IVe.Instead, the redirecting sub-step IVg, where the location entity 40 is connected via the client application 30 to the requesting entity 50, isnowperformed suchthatittransferstheidentity- related information IRI. In that scenario, the location entity 40 interactswith the user 20 insub- stepIVd,sothatthe user 20 authenticateshimself. In somecases,the user 20also 

should confirm the identity of the requesting entity 50 in sub-step IVd because the location entity 40 cannot rec- ognize the requesting entity 50 by itself. 

[0051] Fig. 4 shows a schematicillustration of themes- sage flow of a third embodiment in which a secure chan- nel is assumed, as it can be provided by a secure hyper text transfer protocol (HTTPS). The secure channel is assumed between the requesting entity 50 and the client application 30 (not shown). The third embodiment is browser-specific. That means, the client application 30 is here a browser 30 that is controlled by the user 20. A further column is therefore introduced in Fig. 4 on the left-hand side of the figure and labeled with person 20 that implies the acting user 20. The user 20 is requested to interact with the browser 30. In step I the user 20 is browsing to the requesting entity 50. The location- re- quest step II can sometimes be omitted as in known so- lutions if the browser 30 visited the requesting entity 50 before, and there is either still a session open, or the requesting entity 50 sets and the browser 30 accepts cookies,orthebrowser30 automaticallytransfers certain user settings. In the sub-step IIa a form with a location query is transmitted from the requesting entity 50 to the browser 30 and presented to the user 20. The presenta- tion can be performed in the way as shown in Fig. 5, where the user 20 uses options to submit the location information LI that possesses the identity-related infor- mation IRI. The location information LI is sent as "local- host", which indicates that the location entity 40 is on local, or address to the requesting entity 50 in sub-step IIc. Sub-step IIa and sub-step IIc locate thelocationentity 40 in preparation for the redirecting step III. If all location entities 40 (only one is shown here) were local, the redi- rect could be to a fixed port at "localhost"; similarly, with just one remote location-entity holder, the redirect could be directlytothat.However, differentremote locationen- tities 40 have to be distinguished, and even one user 20 can have multiple location entities 40. The simplest way to build the overall user interaction for these steps is to show the user the above-mentioned form on a screen as shown in Fig. 5. The redirecting step III comprises the sub-step IIIa, now an HTTP redirect, wherein a contact address is transmitted from the requesting entity 50 to thebrowser 30 andthe sub-stepIIIbwhereinthe browser 30 is connected to the location entity 40. The contact address contains a protocol binding, which may be HT- TP, but also another protocol such as a SOAP (Simple Object Access Protocol) binding. Additionally, a session identifierSID istransferred for use insub-stepIIIb.Trans- fer of other information like the last URL requested in step I is possible but less recommended because it may violate the user’s privacy towards the location entity 40. If the requesting entity 50 guesses that the desired iden- tity-related information IRI is short, it can immediately include the exact request and the return address (usea- ble in sub-step IVg). If it is sure, it may even omit the contact information. A safe definition for "short" is that the resulting overall URL in sub- step IVg will not exceed 

