Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Higgins Password Manager

Revision as of 09:37, 9 March 2009 by Ptrevithick.gmail.com (Talk | contribs) (New page: 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 a...)

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

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

Back to the top