IIWdinner

Desktop auth for RPs

• • Use oauth desktop flow between client and RP

  • If client can pop up browser, do it that way

  • If not, show PIN and tell user to go type it in somewhere

  • Either way, OpenID is still in a browser and can be a normal RP

  • Even if using a remote browser isn’t ok, you could take direct credentials for some OPs

    • But this really doesn’t work in the general case

  • Good enough for Google

  • Long pole: need to rev desktop UI

  • Existing RP users with local account credentials can still enter local credentials (LSO style?)

Hybrid OpenID/OAuth without request token

• • Oauth for desktop -> openid is always in browser -> hybrid is always in browser -> get rid of request tokens -> consent page can auto-generate and return pre-authorized request token

  • For registered consumers, need to verify callback realm -> just register it as part of getting consumer key

  • For non-registered consumers, need backchannel to prevent front-channel sniffer from getting only credential needed-> use DH handle/secret as consumer token/secret -> send openid.realm during association

    • Large providers may always require out-of-band registration (lawyers), but there won’t be many of these, and they’ll be big, since small guys will have to support unregistered consumers if they want to get traffic while small

    • Fine to show extra warning message on consent page for unregistered consumers

  • No solution for expired associations -> tell RPs to re-associate even if their existing association is “close” to expiring (to prevent race conditions)

  • Worst case, fail and retry or just accept OpenID auth without Oauth creds

Unregistered hybrid consumers

See hybrid above

Login UI for RPs using buttons / urls / emails

• • RPs really want to ask their users, “what service(s) do you already use that have the data my service needs?”

    • Often quite a different question from “what email address do you normally use”

  • Most RPs will know the big providers of the data they need  they’ll be happy to put big buttons for those sites, since getting the data improves on-boarding

  • If there are open standards for getting this data, RPs can still support the “long tail” with an “other” option that presents a combination of: more buttons, domain/openid-url/email for the provider

    • Small providers will have to educate their users on how to access this data on sites without buttons for them

    • Over time, as new services become popular, RPs will add butons for them

    • Doesn’t preclude email providers hosting emailXRDS docs that list services on different providers

  • Most OAuth SPs will become hybrid OPs/SPs so that users can use them for both login and data access on new sites

    • It’s fine for OP/SPs to also be RPs, and the auth chain works as expected

    • In the future, OPs may aggregate access to other SPs, but for now it’s easier for SPs to become hybrid providers

    • RPs will still want email addresses in the short term, but that’s ok cuz SPs/OPs already have them and can give them out with user consent

  • Just need to demonstrate some on-boarding success stories of RPs pushing hybrid OP/SPs and the rest will follow

Gmail Portable Contacts provider

• • Update shindig-java to support 3-legge oauth (copy the fix we made for shindig-php, i.e. let the oauth token return the associated userid during verification)

  • Update OSFE’s implementation of OAuthLookupServicce to pull the gaia id associated with the oauth token and use it for the opensocial REST request

  • Make sure gmail can talk to OSFE via Focus Backend (dust off old protobuf binding from 9 months ago if needed)

  • Punt if needed on orkut support (UI for showing authorized 3rd party apps, scope to activity streams, etc.) and focus on oauth  read only people access for gmail data