ISSUE-137 - Require Identity Signal whenever URLs are displayed

http://www.w3.org/2006/WSC/track/issues/137

We did a straw poll after discussing in the meeting last Wednesday. The 
choices were: 

A) "The identity signal MUST be part of primary user interface when any 
identity sources that are from unauthenticated or untrusted sources are 
(also) part of the primary user interface. These sources include URLs." 

B) If a positive form of identity is availble, the identity signal MUST be 
part of primary user interface when any identity sources that are from 
unauthenticated or untrusted sources are (also) part of the primary user 
interface. These sources include URLs."

C) Do nothing

The results were: 

A - Tyler
B - Johnath, PHB, Bill D, tlr, Mike M, Mez, Anil, Stephen 
C - Ian, Maritza, Jan Vidar, Yngve

That is strong enough to put something into xit, but not, to my mind, 
strong enough to close out the issue. In particular, Yngve said "we need 
more exploration of the possible issues". 

So I'd like to ask the editors (Anil and Thomas) to put the text into xit. 


I'd also like to ask participants to consider and "voice" more issues or 
alternatives on this one. The idea, as you'll remember from the 
discussion, is that in usecases we recognize that the URL is a form of 
identity signal that attackers (such as phishers) regularly manipulate as 
part of their attack. In fact, the entire approach of antiphishing phil 
(which doesn't seem to be in our bookmarks) is to teach people to 
recognize potential attack URLs. Since we are recommending a better 
identity signal, it should be used to retrain, counter act, or contradict 
the URL as an identity signal. Variant B was proposed since one issue was 
the concern around requiring extra screen space when the user is going 
something that is not TLS protected and it is not an attack, arguably the 
most regular state. Would watering it down further with SHOULD be 
attractive to folks with reservations, or is that not the point? More 
thoughts?