Some ideas are from http://wiki.mozilla.org/Firefox3/Location_Bar.
URLs are currently used as the primary source of identity of a web page/site/service by most user agents, and in some cases, there is little else for the user to use to determine the identity of a web site. However, users cannot parse and do not understand the parts of URLs. They also do not understand the security properties of URLs. Since there are few restrictions on how similiar two URLs are when presented to the user, malicious sites have been able to use a wide variety of techniques to ensure that their URLs seem to represent some (other) legetimate web site.
When it is available, a better source of identity for the user is an indication of past user experience with the web site. User agents can provide that based on browser history, bookmarks, password management tools, and other more specialized ways for users to indicate familiarity or trust. The identity of a site is strengthened when it is based on both the site portion of a URL, and some form of site authentication (such as SSL/TLS server authentication).
Risk in this context is the harm that may come to the user, based on a web page/service successfully convincing that user that its identity is other than it is.
In no/low risk situations, if it is used, presentation of URL information should be structured/parsed to present to the user the part(s) most meaningful and useful to the user. Often, the site is key. That part of the URL (the host) should be presented so that the user understands it represents the site/server. Other parts should be removed (such as user:pass login information, and port). Less familiar parts of URLs, such as login information, have been used successfully to spoof users. Care should be taken that the most pertinent parts are clearly presented (in traditional textual displays, that would be the two right most components of the domain name, such as "w3.org"). If the presentation cannot show all of the critical part of the URL host name (for example, because of extreme minimization), then it should not be presented. Users should be able to request any part of the URL, or the whole thing, whether or not the URL is presented as part of default interactions.
In the presence of some other security indicator that includes whether or not SSL/TLS is being used (such as the padlock), the scheme being "https" conveys no additional security information. Therefore, it does not enhance security to display it. Having two ways to communicate the same information may confuse users. Having some way to "unpack" suitcase-like notions (such as the padlock) to see details is desirable (and will be covered in another part of the recommendations). Leaving the scheme off the URL will ensure that redundant information does not inadvertantly mixed signals. For example, a security indicator might choose to indicate no useful authentication in the case of a self signed certificate used for SSL (and no other user agent knowledge of the site).
Putting the favicon in or near anything that conveys security related information confuses the user (spoof sites make it a padlock to benefit from that confusion). This issue is expected to be covered in other parts of the recommendation.
In medium/high risk situations, meaningful and robust security indicators should be linked to any presentation or interactions that the user relies on or is engaged in. Other recommendations (will) cover user input. In the case of pure display, the identity of the site may be expected to be important or meaningful to the user if the display contains user-specific information (particularly of a sensitive nature), or other authoritative data that the user may base actions on (such as flight schedules, weather, and so on). The site identity must be presented with both meaningful identifying information and understandable security properties. Understandable security properties include the existance and name of a user generated bookmark (or other user generated reference managed by trusted user agents), history of interactions with the site, or site reputation from a third party (such as a certificate authority).
Some users attempt to make security decisions about a web page/service before they go there. Given the regularity of announced attacks and vulnerabilities, considering the security of a site before visiting it should be encouraged and supported, even though it is not likely to be the default user behavior. The user might have the URL to type in hand (by copying or memorizing it from some other medium), they might have a link they are thinking of clicking on (from search results, from social software, from a web page), or some action they take through another user agent or device might be understood by them to take them to a web page. In the case of having the URL to type (or copy), the only information avaialble is the host portion of the URL. We can imagine utilities in user agents that might take such a URL and do a "pre fetch" of identity and trust information, but that option is not currently available in web user agents. In the other cases, there is a user agent who should present or make available extra identity information, such as that available when the site is accessed. Not all identity information may be availabe before going to the site. For example, initiating SSL sessions to extract the authentication information in a page of links would take significant bandwidth, some amount of CPU, and might trigger security alerts. Other identity information is readily available. For example, the information about whether or not the link has been followed before (of displayed as a color difference in displayed links) is a subset of this information (is this a site I've been to before? what if anything have I done there?). Some user agents make the URL of the link available, for example, when the link is moused over. More useful still from a security point of view is presenting whatever information is available on how familiar/trusted this site is to a user (as discussed above).