Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "ISS Web UI"
(→Overview) |
(→Overview) |
||
| Line 1: | Line 1: | ||
==Overview== | ==Overview== | ||
| − | The [[ISS Web UI]] is invoked by | + | The [[ISS Web UI]]'s main method getCard(RP_Policy) is invoked by [[RP Protocol Support]] and returns a matching I-Card handle. |
| − | The [[ISS Web UI]] receives the relying party's ''policy''. This policy describes the forms of digital information that it desires/requires, the | + | The [[ISS Web UI]] receives the relying party's ''policy'' (RP_Policy). This policy describes the forms of digital information that it desires/requires, the token or data stream formats that it supports and the set of claims it requires. It first invokes the [[I-Card Selector Service]] to find a set of zero or more cards that match. (See [[I-Card Selector Service]]). |
| − | If there is more than one card that satisfies the policy, then the [[ISS Web UI]] displays a visual "I-Card Selector" UI that shows all of the user's cards. Cards that don't satisfy the policy are greyed out. If the user clicks on one of the non-greyed-out cards, then they have thereby indicated that they approve the release of identity information that is implied. [[ | + | If there is more than one card that satisfies the policy, then the [[ISS Web UI]] displays a visual "I-Card Selector" UI that shows all of the user's cards. Cards that don't satisfy the policy are greyed out. If the user clicks on one of the non-greyed-out cards, then they have thereby indicated that they approve the release of identity information that is implied. The selected card is returned to [[RP Protocol Support]] |
| − | If no cards satisfy the policy, but the policy accepts self-issued cards, then the | + | [[RP Protocol Support]], knowing the protocol to be used in interacting with the RP, determines whether a token or an RSS feed, etc. is required, the kinds of tokens, information schemas, etc. that are required, and so on. It then queries the appropriate method (e.g. TokenIssuerCard.requestDigitalIdentity() for a TokenIssuerCard or the IdAS methods for an IdASCard) and obtains the desired information. Its final step is to convey this information to the Higgins client using the appropriate protocol (e.g. HTTP POST of a token, URL, etc.) |
| + | |||
| + | If no cards satisfy the policy, but the policy accepts self-issued cards, then the [[I-Card Manager]] will be invoked to allow the user to create a new card (presumably containing the required claims). | ||
==See Also== | ==See Also== | ||
Revision as of 17:57, 15 November 2006
Overview
The ISS Web UI's main method getCard(RP_Policy) is invoked by RP Protocol Support and returns a matching I-Card handle.
The ISS Web UI receives the relying party's policy (RP_Policy). This policy describes the forms of digital information that it desires/requires, the token or data stream formats that it supports and the set of claims it requires. It first invokes the I-Card Selector Service to find a set of zero or more cards that match. (See I-Card Selector Service).
If there is more than one card that satisfies the policy, then the ISS Web UI displays a visual "I-Card Selector" UI that shows all of the user's cards. Cards that don't satisfy the policy are greyed out. If the user clicks on one of the non-greyed-out cards, then they have thereby indicated that they approve the release of identity information that is implied. The selected card is returned to RP Protocol Support
RP Protocol Support, knowing the protocol to be used in interacting with the RP, determines whether a token or an RSS feed, etc. is required, the kinds of tokens, information schemas, etc. that are required, and so on. It then queries the appropriate method (e.g. TokenIssuerCard.requestDigitalIdentity() for a TokenIssuerCard or the IdAS methods for an IdASCard) and obtains the desired information. Its final step is to convey this information to the Higgins client using the appropriate protocol (e.g. HTTP POST of a token, URL, etc.)
If no cards satisfy the policy, but the policy accepts self-issued cards, then the I-Card Manager will be invoked to allow the user to create a new card (presumably containing the required claims).