Cloud -or- Client -or- ... Selector

Issue/Topic: VERIFIED IDENTITY CLAIMS – Selectors (W3A)

Convener: Craig Wittenberg (Microsoft)

Notes-taker(s): Ariel Gordon (Microsoft)

Tags: Identity Selectors; Verified Claims; Identity Attributes; Privacy; Privacy Enhancing Technology; User-control.

Participants:


 * Craig Wittenberg	Microsoft
 * Ariel Gordon	Microsoft
 * Pat Mangiacotti	Equifax
 * Mary Ruddy	Meristic
 * Brian Kissel	Janrain
 * Greg Hauw	Ohanae
 * Brad Hill	ISEC Partners
 * Dale Olds	Novell
 * Pamela Dingle	Ping Identity
 * Van Miranda	Socialcast
 * Diana Smeltas	Google
 * Naveen Agarwal	Yahoo
 * Eric Sachs	Google
 * Paul Trevithick	Azigo
 * Dave Hebert	Microsoft
 * George Fletcher	AOL
 * Lloyd Burch	Novell
 * Greg Turner	Sierra Systems
 * Michael Fischer	Stanford
 * Jeff Hodges	PayPal
 * Eve Maler	PayPal

Discussion notes:

Verified Identity Claims – How to implement identity/claims selectors

Scoping to the scenarios where privacy requirements mandate a “separation” between claim provider and relying party, e.g. non traceability.

Framing from the perspective of verified claims—adds some requirements. However, the model can be used for any type of claims (verified or self-asserted).

Problems: where should the Selector run?
 * If the selector runs on the client, we need to update/manage its lifecycle, enable portability/roaming, etc.
 * If the selector runs in the cloud, then one of the major question is who has the keys? (with U-prove tokens, the agent is storing the keys). In this case, the cloud service has the keys and could potentially impersonate the user.

There are many potential UX problems…

We should separate the Login problem from the Exchange of verified claims problem. Does the user need to authenticate to the cloud-based selector?

Potentially, the user may need to authenticate N+1 times (once to the selector and N times for the N claim sources)…

Paul Trevithick (Azigo): Having the Selector remember my passwords to IdPs/Claims provider is a bad design.

Long-live tokens can address part of the problem because the selector could retrieve a bunch of tokens from the Claims provider to spend later—and not have to save the credentials.

George Fletcher (AOL): the Cloud Selector will now more about what the user is doing than the IdPs and the RPs.

That’s true— but if it’s operated as a different party from the IdP and is under the user’s control, this is already better than the current IdP-centric model. However, it is true that the cloud selector becomes the center of this relationship knowledge, and this is clearly one of the downside of implementing the selector as a cloud service. Implementing as a device local service would mitigate that. There might be other, “hybrid” options with limited functions that run on the client.

Pamela Dingle (Ping): think of this as a User-centric Attribute Broker (instead of a selector/agent).

The authentication methods are left to the service providers (outsourced).

Elements that will influence the design process:
 * Multiple tokens
 * Login to IdP vs. long live tokens; extra auth?
 * User preferences
 * Nascar
 * What drives discovery? Should there be a way to provision the relationship with IdPs/claims providers to the selector?

Eve Maler (PayPal): Standardizing claims type (building a dictionary?) and referencing valuable claim sources?

Goal: valuable claims need to be available for everyone. Possibly offered my multiple providers.

Paul: This may be the reinvention of user-centric identity and links naturally to the Personal Data Store discussion.