Should scenarios capture more UX?

[dwaite]

Apologies if this is not the best place to discuss this.

While the initial document version does a good job of summarizing the cross-domain federated flow, I'm not sure it goes far enough in capturing the potential user experience when browser state is limited. To provide a few UX examples:

Single Sign-on:

• Multiple different sites can participate in single sign on with only a single user authentication at IP1

Transparent SSO:

• IP1 may decide to not prompt for user consent if it recognizes the user has previously given consent to RP1

Transparent SSO as site integration:

• IP1 may use SSO across domains as a mechanism for integrating different pieces of functionality provided by different products (possibly under different hosting providers). Transparent SSO may be used to make services appear part of a single experience.

Anti-Phishing via Device Tracking:

• IP1 may have a security policy where the user must approve a browser (as a "new device") if IP1 does not detect the user has previously interacted from that particular browser.
• IP1 may provide notifications about unrecognized devices as security events
• IP1 may provide the user the ability to view different devices and activity if they are concerned someone has access to their account

To me, this seems better for guiding design - for example, device tracking is an example of a security feature which requires persistent ( and > 7 days) state, while transparent SSO is an example of a feature that breaks if every use of the browser API requires user confirmation.

[gffletch]

I think these are all valid use cases. Can we document them individually where the focus is on the UX and browser requirements needed to enable that UX? I think it will be simpler if we keep the use cases narrow in focus.

Thoughts?