IdentitySelector

Differences between revisions 2 and 8 (spanning 6 versions)
Revision 2 as of 2006-11-04 15:34:15
Size: 640
Editor: c-71-196-138-19
Comment: phishing risks
Revision 8 as of 2006-11-05 16:06:10
Size: 2472
Editor: c-71-196-138-19
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/identity-selector
 * '''Created''': [[Date(2006-11-04T15:30:00Z)]] by NealMcBurnett
 * '''Contributors''': EricNorman
 * '''Packages affected''':

== Summary ==
Line 2: Line 9:
based on growing support for "Laws of Identity" and frustration based on growing support for "Laws of Identity" (see reference below
or [http://www.identityblog.com/?page_id=352])
and frustration
Line 6: Line 14:
to use with web services. One promising leader to use with web services.

To guard against phishing, the identity selection should take place in a protected subsystem (similar to the login screen).
The user should get a clear and unmistakable signal that she is indeed
talking with this protected subsystem and not something that just looks like
one provided by a phisherman.

== References ==

For more information about CardSpace (nee InfoCard), a real good place to start is
[http://www.identityblog.com] (documents on left side).

== Rationale ==

Providing a
user interface which makes it clear to the user that they are interacting directly
with a layer of the operating system that is more resistant to attack than the
browser or other application would increase user confidence and reduce phishing attacks.

== Use cases ==

== Scope ==

This spec is focussed on the client side.

Besides an Identity Selector, other Ubuntu specs are needed for other
InfoCard support services. E.g. probably a
Card Store to store a user's cards; a log ala the Microsoft "Ledger" that tracks a user's usage of cards at various sites/services; and a Self-Issued Identity Security Token Service (STS) that can be an identity provider for self-issued cards.

Support for the server side (Relying Parties) and for Identity Provider implementations will come through applications such as Apache.

== Design ==

The Identity Selector would probably consist of a protected user interface, and a protocol module
to get tokens via interactions with Security Token Services.

== Implementation ==

One promising code base
Line 12: Line 58:
To guard against phishing, the identity selection should take place in a protected subsystem (similar to the login screen). == See also ==

 * NetworkAuthentication
 * AuthenticationInfrastructure

----
CategorySpec

Summary

Identity metasystems are finally beginning to mature, based on growing support for "Laws of Identity" (see reference below or [http://www.identityblog.com/?page_id=352]) and frustration with the problems of userid/password authentication.

Users will want OS support for securely selecting identities to use with web services.

To guard against phishing, the identity selection should take place in a protected subsystem (similar to the login screen). The user should get a clear and unmistakable signal that she is indeed talking with this protected subsystem and not something that just looks like one provided by a phisherman.

References

For more information about CardSpace (nee InfoCard), a real good place to start is [http://www.identityblog.com] (documents on left side).

Rationale

Providing a user interface which makes it clear to the user that they are interacting directly with a layer of the operating system that is more resistant to attack than the browser or other application would increase user confidence and reduce phishing attacks.

Use cases

Scope

This spec is focussed on the client side.

Besides an Identity Selector, other Ubuntu specs are needed for other InfoCard support services. E.g. probably a Card Store to store a user's cards; a log ala the Microsoft "Ledger" that tracks a user's usage of cards at various sites/services; and a Self-Issued Identity Security Token Service (STS) that can be an identity provider for self-issued cards.

Support for the server side (Relying Parties) and for Identity Provider implementations will come through applications such as Apache.

Design

The Identity Selector would probably consist of a protected user interface, and a protocol module to get tokens via interactions with Security Token Services.

Implementation

One promising code base is OSIS - Open Source Identity Selector, which intends to be at least as functional, and fully compatible, with Microsoft's CardSpace (formerly known as InfoCard) identity selector that will be shipped with Windows Vista.

See also


CategorySpec

IdentitySelector (last edited 2008-08-06 16:35:43 by localhost)