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

From IIW

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:



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:


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


  • + 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


  • 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


  • 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