I2 Identity Selector Invocation
From OSIS Open Source Identity Systems
(Redirected from I2 IA Selector Invocation)
This section represents variations in the way that an Identity Agent (also known as an Identity Selector) can be invoked by a Relying Party.
Note that some sections of this page are not applicable for some Identity Agents.
Browser Based Invocation
| Description | Acceptable | Not Acceptable | Examples/Tests |
|---|---|---|---|
| RP invokes selector by basic HTML <form> tag, submitted by user selection of an <input> element | accept or actionable message | ignore or failure | Test 1A |
| RP invokes selector by basic HTML <form> tag, submitted via javascript | accept or actionable message | ignore or failure | Test 1B |
| RP invokes selector by javascript form, submitted via javascript | accept or actionable message | ignore or failure | https://www.cardspacedemos.com/FriendsWithCards/ |
| Invocation content communicated via an HTML object | accept or actionable message | ignore or failure | http://self-issued.info/ |
| Invocation content communicated via an XHTML object | accept or actionable message | ignore or failure | http://pamelaproject.com/wptest/ |
| Invocation content comunicated from an RP/STS | accept or actionable message | ignore or failure | MS Age RP |
Non-Browser Based Invocation
| Description | Acceptable | Not Acceptable | Examples/Tests |
|---|---|---|---|
| Manual Invocation of Selector by end user [H: this is a feature not an interop point] | icon on desktop or in browser | No way to manually invoke, or long command string | not yet |
| Web-Services invocation of Selector | accept or actionable message | ignore or failure | not yet |
- Neither selector behavior nor RP behavior is standardized; it is not straightforward for users to know what to expect when using information cards with different selectors, or with the same selector but a variety of RPs. (Bob)
- It was observed that some RPs are using different approaches to detecting and triggering identity selectors; this caused some failures. (Bob)
- Some RPs exhibited different behavior on first visit (required registration of some sort) versus subsequent visits. (Bob)
- (NI) ??? This seems like typical and desirable behavior in many cases. (Eric)
- Consistent detection of Identity Agents associated with a browser ‑‑ We need a browser‑independent convention for Identity Agents to be able to communicate presence (and preferably capabilities) to a Relying Party, *without* misrepresentation. (Pam)
- I would say that we just need a consistent detection of an IA, as these don't have to be browser based. (Tony)
- Consistent set of industry‑wide "supported methods" for triggering Identity Agents ‑‑ The simple "embedded object" method must be expanded on ‑‑ As a minimum, how about objects submitted via Javascript (Pam)
- Refined RP requests / alternatives : (token type, issuer, claims) sets. There are use cases where RPs need to group alternatives for the requests. E.g. TokenType1 from Issuer1 with ClaimSet1, TokenType2 from Issuer2 with ClaimSet2 etc. Currently there's only one pool for these request parameters. (Johnny)
- A standard set of error codes should be returned when i‑card selector fails.For example, ignoring the already mentioned problems related to identifying which IA (or any!) is being used, RP sites need to be able to tell the difference between "i‑card selector crashed" and "user selected no card". Also, it is debatable whether the RP should be allowed to know the difference between the "user chose not to select any card" and the "user had no matching card". RP sites would certainly like to know the difference, but I suppose some folks might argue that this is a identity information leak. (Paul)
