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 emailXRDS 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