Talk:Papers:Sending the Right Signals

beltzner, Jan 25th, 3am PST

• first draft completed and ready for comment
  • feel free to make grammatical/spelling edits inline, I haven't bothered to do that check yet
  • if you find it easier to insert comments in the text itself, again, feel free
• with screenshots, this will be 4 pages in length
• I used "trustworthiness" a lot, instead of "authentication"; is that OK?
• dbaron said that the goal of these meetings was to generate discussion, and that was the approach I took as opposed to attempting to design the perfect UI, since the underlying technologies aren't neccessarily finalized, and since it's not yet determined if there will be multi-level authentication or preferred CAs. As a result, I tried to keep the position paper at a general level, commenting on what's needed as criteria for success for any solution. That said, I tacked on some simple proposals at the end :)
• On a re-read, I think I might need to tie together the idea that I'm approaching this from a "how do we make online authentication as close as possible to the real world equivalent" or "what can we learn about how we already make these judgements in order to apply that to the UI" perspective.
• I'm rambling, aren't I? I'll stop now.

Hecker 09:24, 25 Jan 2006 (PST)

This is a useful beginning. Some quick comments:

• Using "trustworthiness" and similar terms is I think OK, as long as you are taking the perspective of the end user, who ultimately is the one making the decision on whether a particular service can be trusted (as in your RL examples).
• You write, "A connection to an entity should be said to be 'secure' when the connection is encrypted and it can be reasonably assured that communication is restricted to the user and the entity." One key question is, what does "reasonably assured" mean in this context? For example, by one interpretation connections made using self-signed certificates could be referred to as "secure", at least if there is some reason to believe that the certificate in question is in fact associated with the entity in question. (For example, the self-signed cert may have been exchanged out-of-band, or the user may have identified it as being associated with the entity based on other signals.) Another key question is, what does "entity" mean in this context? For example, some might interpret 'entity' as referring to the web site itself (i.e., a web server accessible at the particular domain name) and others might interpret 'entity' as referring to the web site operator (i.e., an identified individual or organization).
• In general I prefer using the phrase "identified by" to "signed by". My only caveat is that it doesn't read as smoothly in cases where the certificate is associated with a domain name rather than an individual's or organization's name.

A general comment: Let's make sure that this discussion doesn't solely focus on the SSL UI and related PKI-enabled features. In my opinion in the context of the overall problem PKI/crypto are both overkill, because of the technical complexity underlying PKI/crypto-related features, and also at the same time don't necessarily address the problem at hand, because of the ambiguity underlying what PKI purportedly attempts to do.

I think that the "signals" approach is the best way to go: Figure out what signals can provide relevant information to the user who's trying to make a trust determination, and come up with a reasonably unified way to present such signals to the user. The signals themselves could be based on various back-end mechanisms: real-time site checks (as in the various anti-phishing toolbars), crypto-based mechanisms like X.509v3 certs or PGP-style signing, and so on. The front-end UI should be designed to accommodate multiple such mechanisms, both present and future, with such mechanisms either built-in to the core products or addable via extensions.

shaver

In the case of a FOAF or web-of-trust signal, there's no "organization that accepts responsibility for that judgement".

There isn't much in here about letting people federate credentials, reuse them with different sites, or any piece of the authentication/trust space other than "helping users know if they should trust sites". I think the other side of the equation is very important too, perhaps obviously. ("How does Jane know which card the ATM will accept? How does the ATM verify her card and account?")

from call

• the last section is the weakest, and narrows the discussion back to SSL style security which is orthogonal to the rest of the discussion
  • perhaps remove it, or generalize it out some more
• ignores non-browser clients (email, news aggregators, calendar, etc.)
• keep the focus on framing the discussion instead of coming up with prematurely-specified proposals

dria

• Minor quibble: you use "entity" and "object" interchangeably throughout. I found it slightly jarring. I'll leave it to you to decide whether this is actually a valid complaint :)
• The paragraphs about 'consistency' and 'clarity' are a bit jumbled. You start talking about consistency then sort of fade into talking about clarity...maybe talk about why clarity is important earlier in the piece before stating our position (which is about consistency), then just focus on why consistency is awesome in the "Position" section?