Higgins Password Manager

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

This page describes proposed enhancements to the Higgins Browser Extension

Proxy or App Design options

There are two options:

proxy

The password manager acts as a proxy for the "real" RP --thus the domain in the RST is the domain of the site the browser is pointing at

app

The password manager IS the RP --it has its own domain/identity

Tradeoffs

<insert tradeoffs here> [we're leaning towards "app"]

Proxy

• Pro:

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 for NON-SSL sites:
  • required claim = username
  • required claim = password
  • required claim = domain-root>/<domain-of-RP> <-- this claim is not required if the "per-role" design option is employed
  • self-issued issuer
• 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