W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Re: Rec Proposal: Separate in-browser editor for entry of Personally Identifiable Information (PII)

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 2 Apr 2007 15:58:15 +0200
To: "Close, Tyler J." <tyler.close@hp.com>
Cc: public-wsc-wg@w3.org
Message-ID: <20070402135815.GO4111@raktajino.does-not-exist.org>

On 2007-03-21 02:23:04 -0000, Close, Tyler J. wrote:

> In use case 1, Alice has previously provided her login credentials to
> her bank, and so using the PII bar, she logs into her bank by selecting
> the login credentials from the menu provided by her PII bar, rather than
> typing them in herself. In particular, Alice's normal login ritual might
> be:
>     1. Alice positions the keyboard focus in the username text field, or
> the web page puts it there automatically on page load.
>     2. Alice hits an attention key which moves the keyboard focus to the
> PII bar text entry field.
>     3. Alice selects her username by either:
>         3a. using the up or down arrow key to select the corresponding
> text string from the menu of previously provided PII text strings
>         3b. typing the corresponding text string until enough characters
> have been provided for auto-completion
>     4. Alice hits the Enter key, causing the PII bar to paste the
> selected text string into the UI widget that previously had the keyboard
> focus and return the keyboard focus to that UI widget
>     5. Alice moves the keyboard focus to the password text field, or the
> web page does that for her.
>     6. Alice repeats steps 2 through 4 for her password.
> In the typical case, this login ritual is longer than that supported by
> current password managers or form fillers, but I think it provides some
> important advantages.

I wonder if there would be an extension here that might move the
behavior closer to the current environment, by not letting Alice
cycle through elements and attention key sequences multiple times.

A variation might be to assume the existence of a special attribute
on form fields (and throw a corresponding requirement at the HTML
WG), that makes this field unwritable *unless* the user invokes a
secure attention sequence.

More precisely, but still rough:

- When a user attempts to interact with a form control of this
  specific type, the user agent MUST communicate the secure
  attention interaction to the user.  The user MUST NOT permit any
  further interaction with the form control.

  The secure attention sequence MUST be consistent over time.

- Whenever the user executes the attention sequence, the user agent
  MUST enter a mode in which a recognizable widget is used for
  keyboard entry.  This widget MUST NOT be controlled by scripted
  When interacting with this widget, the user agent MUST inform the
  user about the security context in which the user currently
  interacts, including (a) the presence (or absence) of protocol
  level security features in the transaction that led to the
  interaction with of the form, and (b) the presence (or absence) of
  security features for the submission process.

  (I realize that there is a "oops we need to solve the halting
  problem" in here.  One answer could be to suggest "no security" in
  that case.)

I think you get the gist of the idea from this; this would need
further fleshing out and further discussion.

Thomas Roessler, W3C  <tlr@w3.org>
Received on Monday, 2 April 2007 13:57:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:15 UTC