User Challenges with Federated Login!! Follow-up From Day 1

Session Topic: '''User Challenges with Federated Login!! Follow-up from Day 1'''

Wednesday 1B

Conveners: George Fletcher/ Vicki Milton

Notes-taker(s): Vicki Milton

Tags for the session - technology discussed/ideas considered:

IDP

RP

User challenges

Data exchange

User experience

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: '''

There are benefits and drawbacks to being an IDP or an RP, for example:

RP
 * + get out of the password business
 * + lowers sign up barriers to entry
 * - Vulnerable to IDP zigzagging, could go away
 * - account recovery changes

IDP
 * + Ability to follow the user to where they go
 * + greater brand loyalty through continued use of identity
 * - Meeting needs of RP
 * - potential legal liability

This session will explore the impact to users, the benefits and the challenges. We’ll also catalog known unintended consequences from today’s implementations (both good & bad)

User benefits
 * +	Sign in Ease of user
 * +	Better security, less likely to be hacked due to concentrated security investments by big IDPs
 * +	No form fill
 * +	With long term identity relationship, may get greater access to services for having a quality account
 * +	Email as sign in – simplicity and memorability in the username

User challenges

Data exchange Opt-in
 * Not understanding what get’s shared
 * Distinguishing which data is needed for functionality vs. what is being asked for during sign-in
 * Unclear on the potential use of the data
 * Ability for users to easily assess horsetrade
 * Agreeing to data access before perceived benefit
 * Alternative approach of Just-in-time opt-in creates friction
 * The architectural differences between native app vs. server request. Servers will require upfront requests.
 * Must relinquish data to gain service benefits

User experience
 * Forgetfulness, how to recall what was used to login the last time, especially when using long term cookies
 * Still no common ceremony
 * How to determine when the data can automatically be used, vs. a need to ask the user
 * If something goes wrong, who are you going to call, the RP or the IDP

Manageability
 * No user management
 * Lack of control
 * Requirement for a secure and controllable experience

Customer relationship
 * May not know the IDP that is being used
 * If the user is faced with inability to access a paid service, who reimburses the user?
 * The most trusted IDP is not an option on the sign in screen
 * Need to better convey the trust relationship that exists between the RP and the IDP

Unintended consequences

Persona “slamming” – forcing a merge of persona activities due to limited choices of sign ins
 * Need for a persona manager – account user shows last user login
 * Device could play a role in helping the user decide what identities are available to use
 * Increased account security on a core set of IDPs

Lack of flexibility in data exchange approval screens
 * Need for optional scopes – technology is available is isn’t being used
 * Increased difficulty in app developer experience
 * UI design has too many words
 * Need to separate app data needs from marketing promotion data needs
 * Value proposition statements are not included
 * We are habituating consent
 * If you fail to share data, you fail authentication

Users are creating “trial accounts” to see what data is being used
 * Leads to abandonment of trial account once trust is established (they move to IDP account)
 * Site can’t link the identities to see cradle to grave site use
 * Implementations don’t allow a slow build on the relationship

Reduction of passwords might adversely affect the revenue streams of password management software