IdentitySelector

Differences between revisions 7 and 14 (spanning 7 versions)
Revision 7 as of 2006-11-05 06:32:11
Size: 1493
Editor: c-71-196-138-19
Comment: outline rest of spec, reference related specs
Revision 14 as of 2008-08-06 16:35:43
Size: 3493
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
 * '''Created''': [[Date(2006-11-04T15:30:00Z)]] by NealMcBurnett  * '''Created''': <<Date(2006-11-04T15:30:00Z)>> by NealMcBurnett
Line 10: Line 10:
or [http://www.identityblog.com/?page_id=352]) and frustration or [[http://www.identityblog.com/?page_id=352]]) and frustration
Line 13: Line 13:
Users will want OS support for securely selecting identities
to use with web services. One promising leader
is OSIS - Open Source Identity Selector, which
To guard against phishing, the identity selection should incorporate
a clear and unmistakable signal to the user that she is indeed
talking with her own identity selector and not something that just looks like
one, provided by a phisherman. Various [[http://www.schneier.com/blog/archives/2005/07/security_skins.html|security skin]]
approaches can help.

== References ==

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

See [[http://spwiki.editme.com/InteroperabilitySpace|Interoperability Space]]
at the [[http://spwiki.editme.com|spwiki]]
run by [[http://socialphysics.org|SocialPhysics]]
for how CardSpace, Higgins, XMLDAP and Ian Brown's Mac OSX Card Selector
might fit together.

See http://openliberty.org/wiki/index.php/RelatedProjects for other related projects.

See also the July 2006 Linux Journal article by Doc Searls: [[http://www.linuxjournal.com/article/9049|Progress Report toward Independent Identity]]

== 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.

Implementing this purely in an application like a browser leaves the user's identity information more vulnerable, and the user more confused about when it is ok to type in their password.

We will also want to enable more flexible and secure authentication methods for many networked activities besides traditional browsing.

== 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 manage 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 Higgins, which
Line 20: Line 72:
To guard against phishing, the identity selection should take place in a protected subsystem (similar to the login screen).
The user should also 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.
See also OSIS - Open Source Identity Selector
Line 25: Line 74:
== References ==

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

== Rationale ==

== Use cases ==

== Scope ==

== Design ==

== Implementation ==
There is also the [[http://www.bandit-project.org/index.php/Reference_Application|Bandit reference application]]
Line 44: Line 80:
 * ConsistentLoginScreen

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.

To guard against phishing, the identity selection should incorporate a clear and unmistakable signal to the user that she is indeed talking with her own identity selector and not something that just looks like one, provided by a phisherman. Various security skin approaches can help.

References

For more information about the CardSpace Identity Selector and the InfoCard Identity Metasystem, a real good place to start is http://www.identityblog.com (documents on left side).

See Interoperability Space at the spwiki run by SocialPhysics for how CardSpace, Higgins, XMLDAP and Ian Brown's Mac OSX Card Selector might fit together.

See http://openliberty.org/wiki/index.php/RelatedProjects for other related projects.

See also the July 2006 Linux Journal article by Doc Searls: Progress Report toward Independent Identity

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.

Implementing this purely in an application like a browser leaves the user's identity information more vulnerable, and the user more confused about when it is ok to type in their password.

We will also want to enable more flexible and secure authentication methods for many networked activities besides traditional browsing.

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 manage 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 Higgins, 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 OSIS - Open Source Identity Selector

There is also the Bandit reference application

See also


CategorySpec

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