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
- 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
Opt-in
- 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
