the authentication information is controlled inside the Handle System by the users. Recall that each user owns and administers his own handle. As part of this process, the user specifies in the HS_VLIST field the set of handles that have administrative rights over his handle. Among these handles, the user should include handles of any SIP proxy server that he wishes to register with, which could be any foreign server(s) that he trusts. Two approaches can be exploited to implement the logic needed by the cur- rent SIP architecture for supporting handle authentication and registration. The first is to modify the actual SIP servers by extending their functionality through a server plug-in. This approach requires no changes to the current user agent devices whether hardphones or softphones. The devices will adapt seamlessly to the system. Alternatively, a second approach is to modify the user agent devices instead, which is a more cumbersome task that would require software upgrades for all existing user agents. This paper implements the first approach, which deals with extending the functionality of the proxy/registrar servers. We present the proposed solution in light of the reference example of Figure 10.1. In Figure 10.3, the roam- ing user 2118/r_user has granted both SIP proxy servers 2118/hproxy and 10.200/fproxy administrative rights over his handle. Note that the VLIST could refer to another handle containing a list of globally trusted servers. For the roaming user ruser present in the foreign domain fdomain, the authentica- tion/registration process with the foreign proxy server 10.200/fproxy, depicted in Figure 10.2c and Figure 10.1 (proposed traffic flow, arrows a, b, c, d), pro- ceeds as follows: 1. ruser, after including the handle 10.200/fproxy in his handle HS_VLIST field, sends a REGISTER request to fproxy. 2. fproxy challenges ruser to authenticate himself. 3. ruser uses the same digest authentication with handle 2118 r_user as username and the value of the LPWD field as password. He gets these valu