Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Password Card"
m (PWMgr and Password Cards moved to Password Cards) |
(→The Basic Idea) |
||
Line 7: | Line 7: | ||
This page focuses on the username/password subgoal mentioned above. | This page focuses on the username/password subgoal mentioned above. | ||
− | === | + | === Benefits === |
− | The basic idea is to enhance the Higgins client to enable it to login to websites that use username/password authentication. | + | The basic idea is to enhance the Higgins client to enable it to login to websites that use username/password authentication. The client would store the site-specific un/pw data as claims on information cards and leverage the selector's UI to manage these cards. With this enhancement the Higgins client would replace the browser's built-in password manager and offer several advantages: |
* All login-related information (whether un/pw or other kinds of personal and managed i-cards) would be managed in one place under a single user metaphor: the i-card | * All login-related information (whether un/pw or other kinds of personal and managed i-cards) would be managed in one place under a single user metaphor: the i-card | ||
* Since selector's card stores are external to the browser, a person with multiple browsers will have access to all of their passwords on all of them | * Since selector's card stores are external to the browser, a person with multiple browsers will have access to all of their passwords on all of them |
Revision as of 16:46, 3 March 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
As is says on the home page:
- A long term goal is that [the Higgins] client offer what might be called "universal login." This is the ability to log you in to almost any website or app (called a Relying Party (RP)) using a variety of methods including I-Card, OpenID and username/password.
This page focuses on the username/password subgoal mentioned above.
Benefits
The basic idea is to enhance the Higgins client to enable it to login to websites that use username/password authentication. The client would store the site-specific un/pw data as claims on information cards and leverage the selector's UI to manage these cards. With this enhancement the Higgins client would replace the browser's built-in password manager and offer several advantages:
- All login-related information (whether un/pw or other kinds of personal and managed i-cards) would be managed in one place under a single user metaphor: the i-card
- Since selector's card stores are external to the browser, a person with multiple browsers will have access to all of their passwords on all of them
- With a synchronizing selector, the user's passwords are distributed and synchronized across multiple computers and devices
- Security: since few users turn on the optional "master password" protection in their browsers, most user's password data can easily be stolen by malicious browser plugins. With Password Cards the user's data is managed external to the browser and with some Higgins selectors protected by a "master password" that we believe will be used more often than the browser's master password mechanism.
Requirements
a) Support these Password Card Use Cases
b) Adhere to these constraints:
- No extra UI on the browser chrome (e.g. a toolbar)
- Note: Roboform, Google Toolbar require you to click a button on a toolbar
- Automatically highlights fields that it can fill (like Google Toolbar, Sxipper)
- Browsers do not natively do this
- Pure superset of the browser's built-in functionality
Open Issues
What Triggers the fill. Alternatives:
- the user must click in username (or password??) field to trigger fill
- automatic - native password managers automatically fill