[OpenID] Google Removes Relying Party Pre-Registration

Wed Nov 5 00:11:50 UTC 2008

>> I wrote up a quick sketch of an idea in response to Eric's description of
the problem with the OAuth flow for desktop/mobile apps:

Thanks Chris for following up on that issue.  I'll keep on saying it until I
am blue in the face, but we have to get the industry to change the way
rich-client apps are built, or federated login is going to continue to be a
very tough sell.

We have considered an approach along the lines of what you described.  In
particular, some devices want to access a user's data, but do not have the
ability to display a full web browser.  For example, think of devices like
an AppleTV, or a fridge that displays your family photos from
Flickr/Picassa.

One of Google's challenges is that Google exposes lots of APIs such as
Photos, Health, & Ads.  So we want to allow the app to request access to
just a limited set of scopes.  And for some of those scopes (like Health),
we even need the user to choose the access level and profile.  Many OAuth
SPs (like FriendFeed), do not need to support that level of complexity, so
in those cases the approach you described seems reasonable.
For Google, in the "fridge display private photos" example, our team had
suggested something like the following

1) Device/app starts the OAuth dance and also requests a PIN from Google
which Google will associate with the OAuth request token

2) After the device/app gets the OAuth request token, it tells the user (or
its manual tells the user) to visit a short URL (like
fridgephoto/register).  The device then displays the PIN they will need, and
says to come back and click a button on the device when they are told

3) The user goes to a web browser on another device, like their personal
computer, and opens that site.  The site is a static HTML page that gives
some introductory help text, and a link to Google's site to do the
authorization.

4) When the user clicks the link, they are sent to Google with the URLs
parameters for the scopes that device/app needs, and a Continue URL back to
that site, as well as a URL param indicating the user has a PIN

5) They are then sent through the standard Google OAuth approval process.
If the user has not yet logged in, then they will need to do so (and this
might involve a redirection to a SAML/OpenID IDP and/or use of a strong auth
mechanism like a USB token)

5) Once the user is logged in, they see a standard Google OAuth approval
page with information about the claimed app, the scopes, and any advanced
controls such as to pick access level or a profile.  Assuming the user
clicks okay, they are then asked to enter the PIN.  Google confirms the PIN
is a valid outstanding one, and then the user is redirected to the
continueURL (like fridgephoto/authzdone)

6) That device/app's site displays a static HTML file that tells the user to
go back to the device/app and click a button to indicate they finished the
approval process

7) The user click's the continue button on the device/app

8) The device/app then finishes the OAuth dance

Note that an "evil" hacker could request a lot of PINs from Google, and hope
that a user mistakenly types a PIN that is associated with a "hackers"
request token, thereby giving access to the user's data.  As an extra layer
of security, we can send the user an E-mail after an OAuth approval that
used a PIN, with the "claimed identity" of the app, and provide a single
link the user can click to deactivate that OAuth token.  If the user does
more then one approval for the same claimed app in a short period of time,
then on the OAuth approval page we might even give a warning that the
previous one might have been "hijacked" and give them an easily way to
deactivate any recent OAuth tokens issued to the same claimed app.

On Thu, Oct 30, 2008 at 4:32 PM, Chris Messina <chris.messina at gmail.com>wrote:

> I wrote up a quick sketch of an idea in response to Eric's description
> of the problem with the OAuth flow for desktop/mobile apps:
>
>
> http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/
>
> Food for thought. Comments welcome!
>
> Chris
>
> On Fri, Oct 31, 2008 at 7:20 AM, David Recordon <drecordon at sixapart.com>
> wrote:
> > From
> >
> http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html
> >
> > Moving another step closer to single-sign on
> >
> > Thursday, October 30, 2008
> >
> > By Eric Sachs, Google Security Team
>
> > One other question that a lot of people asked yesterday is when a large
> > provider like Google will become a relying party. There is one big
> problem
> > that stands in the way of doing that, but fortunately it is more of a
> > technology problem than a usability issue. That problem is that
> rich-client
> > apps (desktop apps and mobile apps) are hard-coded to ask a user for
> their
> > username and password. As an example, all Google rich-client apps would
> > break if we supported federated login for our consumer users, and in fact
> > they do break for the large number of our enterprise E-mail
> > outsourcing customers who run their own identity provider, and for which
> > Google is a relying party today. This problem with rich-client apps also
> > affects other sites like Plaxo who are already relying parties.
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
>
>
>
> --
> Chris Messina
> Citizen-Participant &
>  Open Technology Advocate-at-Large
> factoryjoe.com # diso-project.org
> citizenagency.com # vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081104/782d4cdf/attachment-0002.htm>