Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Abstract

...

This page describes a real-world use case of a website that supports (or soon will) three identity protocols. What is written here is one of many possible use-cases (interactions) that Alice could have with this site.

Preconditions

  • Alice already has a multi-protocol browser add-on (aka selector, smart client, etc.)
  • Alice has already configured the add-on with five OpenIDs: Yahoo, AOL, Google, Facebook, Janrain
  • Alice has no i-cards configured in the add-on
  • Alice wants to login to the NIH site
  • Alice is not logged in to any of her five OpenIDs at the moment
  • Alice has never been to this site before
  • Alice has not defined a "default" OpenID or SAML or InfoCard
  • The site is a SAML, OpenID, and IMI/InfoCard compatible RP
  • The site trusts Yahoo, AOL, Google, as well as Equifax, Citigroup, Silicon Wave, Acxiom

Flow

  1. The user clicks on a "sign in" button on the NIH site
    • The addon reads some data that tells it stuff like:
    • That the site is an RP for OpenID, IMI and SAML protocols (unusually it does not support username/password!)
    • The list of attributes that the site wishes to receive and for each attribute the list of authorities that the RP trusts. In our case the site is going to request only a non-correlateable identifier (aka an IMI "PPID", aka an OpenID "directed" identity) and that it trusts only Yahoo, AOL, Google, as well as Facebook, Equifax, Citigroup, Silicon Wave, Acxiom to issue this attribute
  2. The add-on displays a login window. It consists of a dropdown showing two accounts that could be used immediately (because Alice has these accounts and the NIH site accepts these accounts), as well as one account that Alice could potentially use if she signed up with Google to get one (but she doesn't have one at present):
    • Google
    • Yahoo
    • AOL
  3. Alice clicks on Google
  4. Alice authenticates to Google
  5. Alice agrees to share Google attributes with NIH

Mockups

Step #1: Alice clicks a Sign-in button (not shown)

Step #2: The add-on displays this window:

Image Removed

Step #3: Alice clicks on Google.

The add-on now displays (hmm...since the add-on knows that Alice already has a Google account, it probably shouldn't show the "Don't have a Google Account?" text):

Image Removed

Step #4: Alice authenticates to Google

Alice types in here username & password and clicks "Sign in" (not shown)

Step #5: Alice agrees to share Google attributes with NIH

Image Removed

V2 Mockups

Step #2 (version 2)

Image Removed

Step #3 (version 2):

Image Removed

Step #5 (version 2):

Image Removeddocument is a product of the Universal Login Experience Work Group. It records the scenarios and use cases governing the development of a cross protocol login user experience.

...

Status

...

This document is currently under active development. Its latest version can always be found here. See the ulx:Change History at the end of this document for its revision number.

...

Editors

...

  • Paul Trevithick

...

Intellectual Property Notice

...

The Universal Login Experience Work Group operates under Option Liberty and the publication of this document is governed by the policies outlined in this option.

...

Table of Contents

Table of Contents
maxLevel2
minLevel1
outlinetrue
indent20px

...

Anchor
intro
intro
Introduction and Instructions

This document is a product of the Universal Login Experience Work Group. It records the scenarios and use cases governing the development of a cross protocol login user experience.

Please copy and revise an existing scenario in adding new scenarios and subordinate use cases. Each use case is created as a separate child wiki page with a name like xyz_scenario and then linked from here. Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:

  • Pending: Initial status when first submitted
  • Accepted: Needs to be accounted for in UMA V1 and/or its associated compliant implementations
  • Deferred: Relevant to the problem space; may be considered in future versions
  • Rejected: Out of scope

Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.

Include Page
NIH Scenario
NIH Scenario

...

(anchor:issues}Issues

Following are discussions of technical issues raised by one or more scenarios and use cases. Acceptance of a scenario or use case will imply agreeing to develop a satisfactory solution to applicable issues.

...

Anchor
change-history
change-history
Change History

Change History