Interop Use Cases

From OSIS Open Source Identity Systems
Jump to: navigation, search

Introduction

The use cases documented here are described in terms of the Interoperability Space definitions.

Edit History

  • 2007.3.20: pd: added a section on Validation Use Cases and also a pointer to the separately created page on Interop_Capabilities
  • 2007.3.19: pd: added a use case to the Site Certificate Display section around display of privacy statement.
  • 2007.3.13: pd: added a link to an RP example of a feature plan that contains "validation" cases.
  • 2007.3.6: pt: started with Mike Jones and Tony's use cases, rewrote everything according to conventions defined below

Conventions Used

  • Each use case has (or will have!) the following structure:
    1. COMPONENTS as defined here
    2. FLOW
      • Sequence: flow sequence (e.g. 1,2,3,4) where flow numbers are defined [as defined here
    3. VARIABLES (optional section)
  • Variables are NUMBERED (not bulleted) items
  • "CS" is short for CardSpace

Authentication to a Service Provider Site

To a CS-compatible Service Provider Site

This section describes various use cases involving authentication to a CS-compatible Service Provider Site.

Site Certificate Display

COMPONENTS

  • Service Provider Site
  • Browser
  • Identity Agent

FLOW

  • Sequence: 1, 2
  • Site certificate is displayed in the IdA when using an i-card at a site for the first time

VARIABLES

Display valid Extended Validation Site Certificate.

Display valid standard Site Certificate in Identity Agent

Display invalid Site Certificate, indicating to the user that something is wrong in Identity Agent

Display link to Privacy Statement, if supported by the Service Provider site

Using CS-interoperable self-issued i-card

COMPONENTS

  • Service Provider Site
  • Browser
  • Identity Agent

FLOW

  • Sequence: 1, 2, 3, 6, 7

VARIABLES

Method used by web site to request the card:

  1. The web site uses the Object HTML extension
  2. The web site uses the informationCard XHTML extension
  3. The web site uses a relying party STS

Using a CS-interoperable managed i-card

COMPONENTS

  • Service Provider Site
  • Browser
  • Identity Agent
  • Token Service

FLOW

  • Sequence: 1, 2, 3, 4, 5, 6, 7

VARIABLES

Schema of the managed i-card:

  1. Schema compatible with self-issued i-card schema
  2. Other schemas

Token type

  1. SAML 1.1
  2. (insert other token types such as SAML 2.0, X.509, and custom token types here)

Means of authenticating to the managed card:

  1. Self-issued information card
  2. X.509 certificate
  3. Kerberos ticket
  4. Username/password

Binding to identity provider:

  1. Transport security binding (HTTPS)
  2. Message security (WS-Security) binding

Proof key type in token:

  1. Symmetric
  2. Asymmetric
  3. None

Other variables:

  1. Method used to request the card (choices as above)

Note: that not all combinations of card authentication method, bindings, and proof key types will be supported by all implementations. For CardSpace limitations see the three Information Card [i-card] protocol documents highlighted in the Technical Papers section of Kim's blog.

Using a Higgins URI i-card

COMPONENTS

  • Service Provider Site
  • Browser
  • Identity Agent (Higgins)
  • Token Service

FLOW ONE

  • Sequence: 1, 2, 3, 4, 5, 6, 7
  • Description: CS-compatible flow. However since flow 4/5 uses a WS-Trust exchange, an STS "head" or "adapter" would have to be incorporated as part of the Token Service (OP).

FLOW TWO

  • Sequence: 1, 2, 3, 16, 17, 6, 7
  • Description: CS-compatible "front-end" flow combined with 16/17 OpenID pseudo-auth to get attributes

To an OpenID Service Provider Site

Using a (Higgins) URI i-card

COMPONENTS

  • Service Provider Site (OpenID-compatible)
  • Browser
  • Identity Agent
  • Token Service (OpenID OP)

FLOW

  • Sequence: <need new flow!>, <need new flow!>, 12
  • User signs in to an OpenID-compatible Service Provider Site using a (Higgins) URI i-card that "points to" the OpenID OP. Higgins simply auto-form fills in the user's OpenID and "steps out of the way" allowing the Service Provider Site to talk to the Token Service (OP) directly (flow #12).

Using a CS-compatible managed i-card

User signs in to an OpenID-compatible Service Provider Site using a CS-compatible i-card

COMPONENTS

  • Service Provider Site (OpenID-compatible)
  • Browser
  • Identity Agent
  • Token Service (OpenID OP)

FLOW

  • Sequence: 1, 8, 18, 4, 5, 19, 11
  • Identity Agent: acts as an OpenID OP for data in token returned from WS-Trust exchange with STS.

Authentication to a CS-compatible Smart Client

COMPONENTS

  • Client App
  • Identity Agent
  • Token Service (optional)

FLOW

  • Sequence: <to be written>
  • <to be written>

VARIABLES

  • All variables are as in the ___ and ___ scenarios, except that no browser is involved and a relying party STS is required
  • <needs work>

Authentication to an IdP

Note: the following use cases involved nested flows. In the initial flow the Service Provider Site is in fact just that. But mid-way through trying to authenticate to the SP, the IdA needs to authenticate to the IdP. This involves a recursive step. Now the IdP becomes the SP in the "sub" (auth) flow.

To Liberty IdP

Using a CS-compatible i-card

COMPONENTS

  • Service Provider Site (the Liberty IdP)
  • Browser
  • Identity Agent
  • Token Service (Liberty IdP)

FLOW

  • Sequence: <to be written>
  • User visits a Liberty service provider. The Liberty IdP requests that the user sign in via an information card. The user supplies an information card to the Liberty IdP via an identity selector, causing the IdP authentication to succeed, causing the Liberty SP authentication to succeed. Variables include:

VARIABLES

  • All the variables from scenarios 1 & 2 are in play

To an OpenID IdP/OP

Using a CS-compatible i-card

COMPONENTS

  • Service Provider Site (OpenID compatible)
  • Browser
  • Identity Agent
  • Token Service (OpenID OP)

FLOW

  • Sequence: <to be written>
  • User visits an OpenID relying party that requests that a phishing-resistant authentication method be used. The OpenID provider (OP) uses Information Card sign-in to provide phishing-resistant authentication. The user supplies an information card to the OP via an identity selector, causing OP authentication to succeed, causing the OpenID relying party authentication to succeed. The OpenID relying party displays a message saying that a phishing-resistant authentication method was used. Variables include:

VARIABLES

  • All the variables from scenarios 1 & 2 are in play

I-card Format Interop

  • Mike's "INFORMATION CARD FILE FORMAT COMPATIBILITY DEMONSTRATIONS"

COMPONENTS

  • Identity Agent

FLOWS ONE

  • Sequence: D
  • Import .crd file into Identity Agent to create a managed card

FLOW TWO

  • Sequnce: <need to add flow!>
  • Create a .crds file to export i-cards from Identity Agent

FLOW THREE

  • Sequnce: <need to add flow!>
  • Read .crds file to import i-cards into Identity Agent

Tony's that still need to be folded in

  1. Cardspace enabled SAML Attribute Authority for attribute exchange
  2. OpenID enabled SAML Attribute Authority for attribute exchange
  3. Higgins enabled SAML Attribute Authority context provider
  4. Authenticate to a OpenID enabled relying party with a CardSpace card over CardSpace protocol (different card types with different tokens)

Validation Use Cases

Validation use cases are of two types - Post-Transaction Data Validation & Message Validation

Post-Transaction Data Validation

  • These cases seek to validate that the right type of data (or lack thereof) was actually stored by the components.
  • Proof of these types of cases involves checking database tables or audit logs

Site Identifier Non-Correlation

COMPONENTS

  • 2 Service Provider Sites
  • Browser
  • Identity Agent

FLOW

  • Sequence: 1, 2 (for each Service Provider Site, using the same self-issued card)

VARIABLES

Display stored PPID for Site 1 & for Site 2 - attempts to correlate should FAIL

Identity Provider Audit/Non-Audit

COMPONENTS

  • Service Provider Site
  • Browser
  • Identity Agent
  • Token Service

FLOW

  • Sequence: 1, 2, 3, 4, 5, 6, 7

VARIABLES

Display audit logs, noting presence or absence of Service Provider Identity

Protocol/Message Validation

  • These cases seek to validate that incorrectly or fraudulently composed tokens or encapsulating protocols do not result in a positive outcome.
  • Proof of these types of cases involves use of a separate component which acts in place of a known good component and sends non-compliant messages.

PPID/Issuer ID Relationship

COMPONENTS

  • Service Provider Site
  • Browser
  • Pseudo Identity Agent (separate component capable of sending non-standard messages)

FLOW

  • Sequence: 1, 2

VARIABLES

Pseudo Identity Agent sends a message containing a privatepersonalidentifier claim whose contents cannot be provably derived from the Issuer's public key. The transaction should FAIL

Token Timestamp Validation

COMPONENTS

  • Service Provider Site
  • Browser
  • Pseudo Identity Agent (separate component capable of sending non-standard messages)

FLOW

  • Sequence: 1, 2

VARIABLES

Pseudo Identity Agent sends a message containing a timestamp which is several days old. The transaction should FAIL.

Component Capabilites

Charts of Component Capabilites are on their own page: Interop_Capabilities

See also

Also see interoperability demonstrations for suggestions regarding what to implement and implementation order for purposes of interoperability demonstrations.