- Good UAs will use a variety of methods to establish which OP to use on which RP. Techniques include:
- analysis of previous interactions on that or other RPs
- user preferences
- UA can collect potential OPs over time by performing discovery during browsing (e.g. using Link header)
- It's possible the RP might blacklist/whitelist specific OPs. Open question as to what best practices are, and whether description of these lists should be part of the Account Manager spec or not.
- InfoCards came up with a spec for which account types they support - "Allows: X, Y, Z"
- Regardless of OP choice, the actual login action is protocol-specific. After login is complete, UA returns to RP and session status should update.
UA<->OP Interaction for OpenID:
- Problem: OpenID does not specify UA-OP interaction, can be completely open-ended. Many OPs require special interaction/disclosure agreement on the first connection, for example.
- Problem: even if we allow for open-ended interaction in a browser tab/window/sheet, it is difficult to know when the interaction is complete.
- Possible flow:
Arrive at OP with checkid_mode and RP/return_to In a sheet/modal frame/doorhanger: OP/login, OP/whatever, until 302 to RP/return_to Poll checkid_immediate after each submit When RP/return_to... read success from URL? hm. or just use success of checkid_immediate to decide and call success/fail action
Preferred UX RelMeAuth