Page Comparison

...

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.

...

Table of Contents

...

General Conditions: IdPs, Users, and RPs

For any given account identity provider (IdP) (e.g. a Google OpenIDOpenID OP, SAML IdP or IMI IdP) three orthogonal, boolean conditions exist:

...

1. The user may or may not have an account on

...

1. the IdP
2. The user either
   1. Has an id-enabled browser that knows that the user has

...

1. 1. an account on this IdP
   2. Has a passive (unmodified) browser OR the id-enabled browser has no knowledge that the user has

...

1. 1. an account

...

1. 1. on this IdP
2. The RP may or may not

...

1. be willing to accept any assertions from the IdP

[Note: if we accept the IdP Selection WG's work as in scope, then doesn't #2 above need to be expanded to include a hosted identity selector agent?]

RP Metadata Requirements

Design Goals

1. Supports a login process that is either triggered by embedded object/markup or triggered by the user clicking on a button
2. Has common semantics irrespective of the option used in #1 above
3. Supports id-enabled browsers as well as passive (unmodified) browsers
4. If it is necessary to embed the RP metadata itself the RP metadata should be base 64 encoded
5. Supports attribute aggregation
6. Supports attribute mapping
7. Supports value-based filtering (e.g. asking for a claim for a particular monetary amount)