Skip to main content
Jump to: navigation, search

Higgins Password Manager

Revision as of 17:00, 23 March 2009 by Ptrevithick.gmail.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

This page describes proposed enhancements to the Higgins Browser Extension

The password manager IS the RP it has its own domain/identity --thus the domain in the RST message is the domain of the password manager. (See Password Manager Design Options for a discussion of the alternatives we considered).

Functionality

After the user points their browser at a new page and and after the web page has been loaded, the password manager would do the following:

  • If both the browser's native password manager and the Higgins password manager are enabled then disable the native password manager.
  • Parse the page looking for a form containing username and password fields.
  • If such form is found, it invokes the selector with the standard "get digital identity" message to the Higgins Selector Switch:
  • If no token is returned (meaning that no un/pw data has been stored in the password cards of the selector) then
    • hook the form submit event
    • after the user submits the form, prompt the user to ask if the use wishes to "remember this password" in the usual manner native to the browser,
    • if the user agrees, then read the username and password from the page and send a "add un/pw" message containing the username, password and RP's domain to the Higgins Selector Switch [note: username and password data are not stored in the Higgins password manager]
    • depending on the metaphor design option, the UX would vary.
      • In the per-role case the selector would search to see if this RP domain was already in one of your password cards and if it was there, ask if it should be replaced. If the domain wasn't present then it would ask you if you wanted to either (a) add the un/pw to one of your existing password cards or (b) create a new password card.
      • In other design options, a different experience would be designed to support replacement/addition of an old/new un/pw pair
  • else [a token is returned], then:
    • hook a click event on the username or password input boxes on the page.
    • after the user clicks, retrieve the username and password from the token and input them into the respective input boxes of the page

Back to the top