...
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
| 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:
- User may or may not have an account (e.g. The user may or may not have an account on Google, or Ohio State, etc.)User the IdP
- The user either
- Has an identityid-enabled browser that knows that the user has an account on this account orIdP
- Has an a passive (unmodified) browser (or OR the addid-on enabled browser has no knowledge that the user has the an account )on this IdP
- The RP may or may not be willing to accept any assertions of any kind from the accountfrom 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
- Supports a login process that is either triggered by embedded object/markup or triggered by the user clicking on a button
- Has common semantics irrespective of the option used in #1 above
- Supports id-enabled browsers as well as passive (unmodified) browsers
- If it is necessary to embed the RP metadata itself the RP metadata should be base 64 encoded
- Supports attribute aggregation
- Supports attribute mapping
- Supports value-based filtering (e.g. asking for a claim for a particular monetary amount)