...
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:
...
- The user may or may not have an account on
...
- the IdP
- The user either
- Has an id-enabled browser that knows that the user has
...
- an account on this IdP
- Has a passive (unmodified) browser OR the id-enabled browser has no knowledge that the user has
...
- an account
...
- on this IdP
- The RP may or may not
...
- 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
- 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)