Becoming an OpenID Relying Party

From IIW

Conference IIW8 Room/Time: 4/C

Convener:

Notes-taker:

Attendees:

Technology Discussed/Considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: Conference IIW8 Room/Time: 4/C

Convener: Luke S, George F

Notes-taker: Brian E

Attendees:

Technology Discussed/Considered: OpenID, UX

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


Six months ago, there were no practices at all, let alone best practices. We now have more experience, but we still don't have all the answers.

Things to consider -

  • password
  • single signout
  • user choice “nascar”
  • linking accounts
  • delegation, or “the ugly long tail”
  • data
  • COPPA
  • contacts
  • technical issues


Question: should user consent pages offer granular choice? Answer: granular choice causes success rate to fall off a cliff.

How can users get more control? Maybe relying parties can ask the user; the user has more context at the RP site. Example: facebook asks the user what they want to import from Google. User selects address book, but not photos. Facebook asks the user only for contacts. This offers user control without requiring users go through a bunch of checkboxes at the RP.

We lose a few percent of people at the approval step because of their privacy concerns. We lose closer to 15% if we offer granular controls on the OP approval page.

Best practice: if an application doesn't require contacts, don't ask for them. IdPs should disincent applications from asking for two much data.


Demo embarassment: RP checks whether an IdP account has already been linked to an RP account, errors if that occurs.

Useful trick: let relying parties discover whether the user is already logged in at the OP, e.g. Use checkid_immediate.

Problem: logging out of facebook doesn't log you out of OpenID IdP. If OpenID IdP offers a “remember me” button, you can't log out of the RP site.

Suggested solution from Luke: every single RP page checks whether the user has logged out of the IdP on every page view. This is what Facebook Connect relying parties do. This terrifies all of the IdPs because of load.

Different relying parties have different needs: small sites can rely on IdP to do everyting, even session management, larger sites don't want that.

Single logout use cases: leaving an internet cafe: you want single logout, leaving one web site: you might not want single logout

Technical challenge: Scott Cantor believes that single logout is “impossible” based on experience from SAML.

Unfortunately, you can't do logout from a single RP if you also support automatic login.

Alternative: maybe make automatic login require a single user click?

Statistical evidence: the more sites that are impacted by single logout, the less users click the “logout” button.

Users are sometimes surprised by SSO; user surprise is a bad, bad idea.


Proposal: when user clicks logout button at RP, RP displays a message saying “you have logged out of the RP site”, and offer a link to signout of the IdP as well.


RP challenge: need to get XRDS file for return_to/realm verification right, or you get an ugly warning from the AOL IdP during sign in. Also need to get a privacy policy in the right place. All of these things require consulting with lawyers to get them fixed.


Problem: users click “Login with Google”/”Login with Yahoo” button even if they haven't used OpenID before and they actually have a password at the RP.

Solution: IdPs should provide e-mail address to allow account unification. Relying parties should only trust e-mails if the IdP is authoritative for the e-mail address. This is a huge pain for IdPs like AOL that offer lots and lots of e-mail domains.


Signing in to AOL example: AOL has to prompt for bithdate for COPPA reasons. Need to ask for display name, and e-mail, and captcha. Had problems with Google openids because “account” is included in the OpenID URL. AOL has a list of words that are forbidden in identifiers (for abuse/security reasons), and “account” was on that list. They had to remove it from the list.

Every OP you deal with has some idiosyncracy you have to deal with.

If you bury the UI where normal users don't trip over it, you can make the OpenID ceremony work.

If you put it in your main flow, it drops the success rate, and that's a non-starter.

Problems to solve to get it on the main flow: single signout

Attribute Exchange is a “nightmare”, because every OP has their own schema, and the schema is not discoverable. You have to read the OP doc to figure it out.

There aren't enough “good Ops” yet. Good OP:

  • support OAuth/OpenID hybrid to get data
  • support automatic login to improve return login
  • returns e-mail for account linking

Why aren't there more relying parties? It's not useful enough.

Key metric: signup friction has to go down.


RP best practice: ignore the URL the user entered, use the claimed ID returned from the IdP. There are too many cases where the URL the user entered can be wrong/mismatched.

Generational recycling: nobody actually gets the fragment stripping right.

Too many corner cases: delegation is a pain to support.

What are we going to do about this?

  • better specs?
  • Bilateral bug fixing?
  • Branding program (consensus: no!)
  • interop test matrix with expected results?
  • Automated test suite that IdPs and relying parties can run?
  • No unit tests ---> poor software quality.


Becoming an OpenID Relying Party

Additional Notes taken by Chris Messina:

Issues

  • password?
  • single sign-out
  • user choice ("NASCAR")
  • linking accounts
  • delegation or "the ugly long tail"
  • data
  • COPPA
  • contacts
  • technical issues

Google has found that asking users to make choices during authentication Eric Sachs: RP should ask for what it needs and nothing more... basically consent request should be made on RP ("who is asking for consent?" "how important is granular release of data?") users aren't smart about making decisions about releasing their data google loses 15-20% of people when they add privacy controls; not having privacy controls costs 3% Demos

Retrieved from "https://iiw.idcommons.net/index.php?title=Becoming_an_OpenID_Relying_Party&oldid=3511"