PII Editor Bar & Trusted Browser Component

I'm reading through the latest state of the PII Editor Bar proposal,
and also the Trusted Browser Component proposal again.

  http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
  http://www.w3.org/2006/WSC/wiki/TrustedBrowserComponent

There are a number of differences on a detailed level -- e.g.,
petnames vs generic shared secrets, and some stuff like that.

I *think* the one significant difference between the two is that PII
Editor Bar proposes a different interaction ritual for generic
forms, and requires significant customization (i.e., the "data
entry" task is redesigned), while the Trusted Browser Component
seems to focus on a single high-level task ("login to XXX") and
introduces a new (possibly simpler?) user interaction for that more
narrow task.

Both proposals seem to get most of their protection out of the
user's lossy memory (if people don't remember passwords, they won't
easily hand them over), and the broken interaction flow when people
log in to an unkown site that they think is the one they were at
before.

Both proposals include some social engineering to steer users toward
a site they've dealt with before in certain failure cases, by making
it easy for them to find out about "existing relations" during the
interaction that would lead to data entry with the site they
currently deal with (and caching of that data / passwod).  I like
that part, and would love to see some empirics on the effect.

PII Editor Bar gets a second level of protection out of a
petname-like UI paradigm; the Trusted Browser Component assumes that
some kind of shared secret has been established to create a trusted
path to the user.  Mentally going through possible scenarios, I'm
suspecting that this particular element of the respective proposals
is the weakest one.

As we move forward, I would like to see both concepts -- the generic
form filler, and the task-specific approach -- tried out and
analyzed.  I have a gut feeling that the task-specific approach that
the Trusted Browser Component suggests might have larger chances for
deployment and user acceptance, based on ease of use when people log
in to sites.

It might in this context be worth looking at the difference between
approaches that (a) require a secure attention key, (b) require a
secure attention key and tell the user about it ("to login to XXX,
please push blah", maybe in one of the nice yellow
chrome-overlapping bars), and (c) don't require a secure attention
key, but simply replace the login interaction.

(Example: PII bar seems to require that a secure attention key be
pressed for every single form field.  TBC seems to only require some
specific interaction to either put a session into a specific mode,
or maybe to effect a login transaction.)

Additionally, it might be an interesting exercise to abstract one
step further, and beyond documenting the specific approach that
comes out useful as a secure data entry ceremony, also write up some
general requirements for secure, interactive credential selection
and/or login processes.

Thoughts?
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Thursday, 16 August 2007 17:19:13 UTC