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.

Edit History

• PaulT: 10/20/2009: added use case #1 flow diagram (see the end of this document)
• PaulT+Valeska: 10/20/2009: Replaced v1 mockup with Valeska's v3 mockup. Removed V2 mockups.
• PaulT: 10/16/2009: Changed preconditions so that Alice is pre-configured with Ohio State IdP and Equifax --now we need to update the mockups to align

Preconditions

Alice:

• Wants to sign-in to the NIH site
• Has never been to this NIH site before
• Already has a multi-protocol browser add-on (aka selector, smart client, etc.)
• Has configured her add-on with:
  • OpenID: Yahoo, AOL, Google, Facebook
  • SAML: Ohio State
  • Infocard: Equifax Identity Card, PayPal
• Is not logged in to any of her OpenIDs or SAML IdPs at the moment
• Has not defined a "default" OpenID, SAML or InfoCard

NIH Site:

• Is a SAML, OpenID, and IMI/InfoCard compatible RP
• Trusts these OpenIDs:
  • Yahoo, AOL, Google
• Trusts these SAML IdPs:
  • InCommon Federation (of which Ohio State is a member)
• Trusts these Infocards:
  • Equifax, Citigroup, Wave Systems, Acxiom

Flow A

Flow A is one of the flows (see the end of this document for more flows):

1. The user clicks on a "sign in" button on the NIH site
   1. The addon reads some data that tells it stuff like:
   2. That the site is an RP for OpenID, IMI and SAML protocols (unusually it does not support username/password!)
   3. 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", OpenID "directed" identity, SAML "persistent" NameID) and that it trusts only Yahoo, AOL, Google, as well as Facebook, Equifax, Citigroup, Silicon Wave, Acxiom, and InCommon IdPs to issue this attribute
2. The add-on displays a login window.
   1. It prominently shows the following accounts that could be used immediately (because Alice has these accounts and the NIH site accepts these accounts):
      1. Google
      2. Ohio State
      3. Yahoo
      4. Equifax
      5. AOL
   2. Its also shows accounts that Alice could use if she first registered with these IdPs
      1. Acxiom
      2. Wave Systems
      3. Citigroup
3. Alice clicks on Google
4. Alice authenticates to Google
5. Alice agrees to share Google attributes with NIH

Mockups of Flow A

VERSION 3

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

Step #2: The add-on displays this "account selector" window:

• Shows these two kinds of buttons:
  • (a) Representations of Alice's list of configured OpenIDs that are ON the RP's white list (shown WITH a blue outline)
  • (b) Representations of the rest of the RP's white list (shown WITHOUT a blue outlne) less those shown in (a)
• The << and >> imply that there are yet other (b)-type IdPs
• Alice's Facebook and Janrain OpenIDs and her PayPal infocards are all not shown in the account selector because the RP site doesn't include Facebook in its white list

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

Flow Diagram

Flow A (described and mocked up above) is the red path:

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

...

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.

...

(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