VERIFIED IDENTITY CLAIMS – Selectors (W3A)

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

Session: Wednesday 3A

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

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

a word diagram goes here

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.