Active Client iiw9

From IIW

At IIW9 several vendors (starting with Microsoft) demonstrated prototypes for an "active client" that would manage internet identities on behalf of the user. Due to broad interest in such capabilities, several of us are getting together at IIW to work on a common description of such Active Identity Clients (AICs) [1] with the goal of driving unified requirements for the necessary infrastructure.

Next Steps

To facilitate this discussion, we will piggyback on meetings taking place Tuesday (11/4) in IIW Room "E" from 11:30 AM until 3:30 PM -- perhaps going straight through lunch.

Agenda

For Tuesday, November 4th at IIW

  1. Scope: What will we focus on? [The "Infrastructure to support user experience"]
  2. Problem: How much complexity will we tackle *now*?
    1. Which protocols: OpenID as it is today, Minimal changes
    2. Perspective: User-centric, implications for RP and IdP
    3. NAME: Active Identity Client
  3. Goal: What do we want to achieve (now or later)
    1. Kinds of information that would be useful
    2. Propose explicit syntax
  4. Dataflow: What are the key components, and how do they relate?
  5. Issues: What are the problems therein that need to be solved?
  6. Proposals: Idas for resolving those problems

Action Items

Markup

object tag or replacement

  • Chris Messina (?)

Callback Model

RP Discovery/Delegation

cf. i-Frame aliasing

Claim Selection

In the IdP, versus the selector (as in InfoCard)

IdP Metadata

names and logos; in process

  • Mike Jones

Validation / Whitelist

  • Ernest Prabhakar

Aligning Popup UX with Selector UX

  • Allen Tom
  • Ariel Gordon
  • Paul Trevithek

Participants / Documents

  • Aanchal Gupta (@aanchalb), Yahoo
  • Andrew Arnott (@aarnott), Microsoft
  • Ariel Gordon (@askariel), Microsoft
  • Axel Nennker (@AxelNennker)
  • Bharath Kumar (@Bharath7923), Amazon
  • RL "Bob" Morgan (@rlbob), U Washington
  • Chris Messina (@ChrisMessina), OpenID
  • Dan Mills (@thunder), Mozilla
  • Dirk Balfanz (@Balfanz), Google
  • Eric Sachs, Google
  • Ernest Prabhakar (@DrErnie), Apple: Chamberlain: A User-Serving Model for Identity Management
  • Gregg Gracheck (@GreggGracheck), Acxiom
  • Joseph Boyle (@JosephBoyle)
  • John Bachir (@JohnJoseph), Ganxy
  • Markus Sabadello, Azigo
  • Mike Ozburn, BAH
  • Mike Hanson (@michaelrhanson), Mozilla
  • Mike Jones (@selfissued), Microsoft: An Experimental Active Client for OpenID
  • Oren Melzer
  • Paul Trevithick, Kantara Kantara Universal Login Experience (ULX)
  • Peter Capca (@pcaperc), IEEE
  • Ragavan Srinivasan (@ragavan), Mozilla: Labs/Weave/Identity/Account Manager
  • Rajeev Angal, Sun
  • Robert Guthrie (@GuthrieRobert)
  • Ronak Shah (@RonakS), Apple
  • Sam Wren (@TelegramSam), Kyneta
  • Sharif Youssef, Acxiom
  • Tom Carroll (@TJ_Carroll), Azigo
  • Ushasree Kode (@ushakode), Yahoo
  • ...

Problem Statement

The key tension we want to address is the paradox that identity management is both a) necessary, and yet b) too complicated for typical users. We want to propose an user-centric solution that is meaningful to RPs and IdPs.

We believe the best way to solve this problem by enabling an Active Identity Client, which manages identities on behalf of the user (though obviously we'd love to enable passive clients as well).

The goal of this discussion is NOT to design a specific Client, but to define the minimal infrastructure necessary to optimally support that class of client.

Client Description

This proposal should enable a wide range of Clients that:

  • Support OpenID and optionally other identity protocols (e.g., InfoCard)
  • Run on different OSes (i.e., Windows, Mac, Linux)
  • Work with modern smartphones (e.g., iPhone, Android)
  • Run in different contexts (browser, cloud, plug-in, desktop, etc.)

Output

The ultimate goal of this discussion is a document that would propose best practices for supporting AICs, including extensions to existing standards (in partnership with the relevant working groups).

Short terms goals may include:

  • forming/joining an ongoing mailing list/working group
  • encouraging prototype AICs
  • building supporting libraries
  • identifying areas for future research
  • documenting areas of agreement
  • putative syntaxes

Client Dataflow

The following are the steps that a typical AIC would likely require:

  1. Detection: website Requesting Party (RP) indicates it supports login via OpenID
    1. Requires them to do something - but only one thing, and once
  2. Initialization: the AIC launches with knowledge of who the user is
  3. Interception: the AIC binds to the websites login so it receives appropriate clicks
  4. Activation: the user initiates/accepts the OpenID login process
  5. Canonicalization: determining the scope of the login for that RP
  6. Discovery: the AIC queries the id attributes requested by the RP
  7. Identification: the AIC determines any IdP's pre-selected by the user
  8. Decision: the user chooses or enters an IdP
  9. Validation: the AIC checks those IdPs against the user's preferences and a security whitelist (blacklist?)
  10. Display: viable IdPs are displayed for the user to select (or, optionally, enter their own new one)
  11. Authentication: the OpenID (or potentially other) protocol is used to authenticate the user via that IdP
  12. Memoization: successful logins are recorded against that website/IdP pair for future reuse

Requirements

To enable that lifecycle, we propose the following supporting infrastructure:

Detection and HTML Markup

While many of us would love Relying Parties to hard-code support for our favored AIC, the reality is that we need a level playing field to encourage both adoption and innovation. This might imply some kind of standard "meta-selector" that would detect the user's preferred (installed?) AIC and auto-launch it on compatible websites.

MS AIC Today (Plaxo)

  • RP places explicit object tag in the page with parameters it needs
    • protocol tag (i.e., openid): one or space-delimeted
    • tokenType (needed by other protocols)
    • issuer - suggested providers (space-delimited) [seen if the users has none pre-existing]
      • OpenID identifiers (shortest form)
    • issuerExclusive (boolean)
    • OpenID parameters inside InfoCard syntax [inline later?]
      • returnTo URL [currently uses browser, be better to do out-of-band]
      • realm [canonical name for always-allow]
      • attributes (required, optional) comma-separated
      • policy_url:
  • specifies MIME-type which invokes a handler
    • x-informationcard used for prototype as it autoregisters with IE
  • explicitly attach JavaScript to login button/anchor
    • or embed the object tag inside the form (auto-invoked on submission)
    • possible to do with a relTag + JavaScript bindings?
  • popup handler when invoked by user
    • if click on a specific providers link, should be able to pre-select that provider in selector

Questions

  • Does the page invoke the AIC (<object>), or is the AIC always present and scanning the page?
    • Alternative is to do just XRDS
    • The former is likely to be the most common case, as it allows lower latency
  • What is the optimal way for the RP to provide metadata
    • Need a simple profile that captures "most" of the cases
  • Can we define a new tag that gets rewritten as <object> as necessary
  • Is there a back-channel for reverse discovery [may be later, for OpenID-OAuth]

Action Items

  • Define the custom tag with specific attributes
  • Define a MIME type
  • Define fallback behavior (e.g., <object> tag)


Ulimately (as with AJAX) the goal would be to define something suitably generic that it could eventually supported directly by multiple browsers, all of which would interoperate with multiple AICs.

Aside: Alternate Credentials

It would be wonderful if this system could easily be extended -- by others -- to support alternate types of authentication besides OpenID

Relying Party Canonicalization

One of the biggest challenges in reusing logins is determining exactly "whom" we are authenticating against *this* time. To that end, the Relying Party needs to provide the "canonical" name used to identity itself, in order to prevent unnecessary logins on one hand and phishing on the other.

There are several potential ways to accomplish this:

  • HTML tags (attribute on Detection, meta tags on the HTML page)
  • ".well_known" URIs on that site
  • Reverse Discovery on the RP

Hopefully we can agree on a common solution that fits well with existing OpenID workflows

Aside: RP-specified Providers

Should the RP be allowed/encouraged to say which providers they support?

Aside: Additional RP Metadata

In many cases, it could be useful to provide "hints" to the AIC about what "kind" of website this is, to enable heuristics about which of various identities to prefer. For example, many users like to use a separate identity for financial websites. While it is beyond our scope to enumerate all possible such usages, we should prefer solutions that enable the RP to easily provide such metadata.

Identity Provider Metadata

For purposes of display and reuse, the IdP Response should include the following metadata in the XRD(S) response:

  • canonical name for the Identity Provider
  • icon tag with metadata about sizes (some recommended sizes, intelligent rescaling)
  • human-readable name

The canonical name would most naturally be an OpenID Endpoint.

The other iterms in the XRD(S) would be localizable based on the HTTP header

Action Items

  • Discussions with Allen Tom from Yahoo! and Luke Shepherd from Facebook
  • In-process with OpenID UX committee

Validation Services

For security reasons it is highly desirable to not let the Relying Party easily specify arbitrary possible IdPs, since it seems likely that eventually there will be IdP "phishers" that mimic well-known sites. On the other hand, it should be possible for users to create their own IdPs (perhaps with feedback about what ones will be accepted).

The optimal model is (for better or worse) is probably one modeled on how root certificates are handled by browsers today (and may in fact leverage that infrastructure). There should be a reasonable set of well-known WhiteList providers that are recognized by default, and authorized users should have the option of explicitly trusting additional sites.

Whether and how AICs represent untrusted IdPs is up to the implementor, though it may be advisable to propose "best practices" thereof.

Questions

  • Who is the authority
    • OpenID
  • How is it published/advertised

Implemented a List of Whitelists

  • Each AIC has a 'root' list of whitelists (which may refer to other whitelists)
    • e.g., Google, Yahoo!, Windows Live, AOL, Orange, MySpace, Facebook
  • XRDs can specify which whitelist they belong to
  • Users can manually add their own (or remove ones they dislike)

Implemented via Certificates

  • Using EV certs as the starting point for whitelists

Rely on AIC to do it their own way

  • Use standard anti-phishing or browser blacklists

Additional Notes

Tags: 
OpenID, ActiveSelectors, Kantara, SAML, InformationCard, CardSpace



Discussion notes:

First demo: Azigo's browser-extension for OpenID identity selector

  • Button on browser toolbar to initiate the identity selector

  • www.openidpad.com is sample RP site

  • Metatag in RP's site causes the button to be shown in the toolbar
- Uses XRDS file for more information, exposes information about RP's needs similar to

InfoCard practices


  • Tells selector what AX information to ask for from the IDP
  • Selector then sends user to the IDP with a request for that information, and then tells it to send an unsolicited positive assertion back to the RP
  • All pages on his RP site include a metatag with a reference to the XRDS file.  That allows the selector to activate the toolbar button on every page
  • Demo has hardcoded list of possible IDPs, but could obviously be enhanced


  • Info PDF at http://wiki.openid.net/f/azigo-openidselector.pdf

Second demo: Adventure Works RP





  • Built with a Javascript client that RP points to with their Login button
- Login button and Visit Members Area button

  • Login button shows Nascar UI

  • He is okay with a few buttons and OpenID button for long-tail, and tells people to use Google to create a new account if they don't have an account with existing buttons or an OpenID
  • All buttons use the popup

  • The site remembers the last IDPs you visited, and put those buttons earlier

  • The site also does background checkid_immediates to all IDPs who have a button and shows a green checkbox for the ones where the user is logged in

  • If the user clicks the OpenID button, then it ajax shows a box below to capture the URL and it supports inames as well.  After discovery is done, it ajax shows a login button that lets the user choose which of the multiple IDPs they may have delegated to.

  • Provides RP account management options to add multiple OpenIDs assocated with same account

Demo: Google's CDS that does NOT use a browser-extension

  • Slides at http://docs.google.com/present/view?skipauth=true&id=ajkhp5hpp3tt_67dvg24phj
- Described at https://sites.google.com/site/oauthgoog/UXFedLogin/central
  • discovery-service

Kantara slides of their UX initiative




  • Described recent group they started to pull together to brainstorm on UX goals without considering the protocol

  • Showed example of the challenge NIH has the with the large number of IDPs it trusts in multiple classes such as schools, consumer IDPs, etc.




  • Gave example of providing a search box over those IDPs

Retrieved from "https://iiw.idcommons.net/index.php?title=Active_Client_iiw9&oldid=3468"