<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Random thought – and no expert in this - but if the
client had some code that used a well known time-based algorithm to generate a
unique token/pin and combined it with a selected OpenID (i.e. the token generated
+openid in the next 60 secs will be the same as the token generated at a remote
location + openid) then could that not be used as the basis of oAuth requests?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I have seen secure token for years which automates this [1] but maybe
through things such as Google gears (which I have on my pda) it would be
possible to provide some simple signed code that could manage this so any
client browser, application etc just makes a call (which *<b>if</b>* really
desired could itself be password protected on the client device) and then you
don’t need to remember any PIN – all the user needs to do is select
the OpenID to use and the “pin” is auto-generated for your device.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I haven’t thought through all the detail, just wanted to see
if anyone had considered this technique?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>steven<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>http://livz.org<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><a href="http://en.wikipedia.org/wiki/Security_token">http://en.wikipedia.org/wiki/Security_token</a><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Eric
Sachs<br>
<b>Sent:</b> 05 November 2008 00:12<br>
<b>To:</b> Chris Messina<br>
<b>Cc:</b> oauth@googlegroups.com; OpenID user experience; OpenID List<br>
<b>Subject:</b> Re: [OpenID] Google Removes Relying Party Pre-Registration<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>>> 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:<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>We have considered an approach along the lines of what you
described. In particular, s<span class=apple-style-span><span
style='font-family:"Arial","sans-serif"'>ome 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.</span></span><o:p></o:p></p>
</div>
<div>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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. <span
class=apple-style-span>Many OAuth SPs (like FriendFeed), do not need to support
that level of complexity, so in those cases the approach you described seems
reasonable.</span></span><o:p></o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>For Google, in the "fridge display private photos"
example, our team had suggested something like the following </span> <o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>1)
Device/app starts the OAuth dance and also requests a PIN from Google which
Google will associate with the OAuth request token</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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.</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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 </span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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)</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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)</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>7)
The user click's the continue button on the device/app</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>8)
The device/app then finishes the OAuth dance</span><o:p></o:p></p>
<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>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.</span><o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Thu, Oct 30, 2008 at 4:32 PM, Chris Messina <<a
href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>I wrote up a quick sketch of an idea in response to Eric's
description<br>
of the problem with the OAuth flow for desktop/mobile apps:<br>
<br>
<a
href="http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/"
target="_blank">http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/</a><br>
<br>
Food for thought. Comments welcome!<br>
<br>
Chris<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
On Fri, Oct 31, 2008 at 7:20 AM, David Recordon <<a
href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>>
wrote:<br>
> From<br>
> <a
href="http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html"
target="_blank">http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html</a><br>
><br>
> Moving another step closer to single-sign on<br>
><br>
> Thursday, October 30, 2008<br>
><br>
> By Eric Sachs, Google Security Team<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>> One other question that a lot of people asked yesterday
is when a large<br>
> provider like Google will become a relying party. There is one big problem<br>
> that stands in the way of doing that, but fortunately it is more of a<br>
> technology problem than a usability issue. That problem is that rich-client<br>
> apps (desktop apps and mobile apps) are hard-coded to ask a user for their<br>
> username and password. As an example, all Google rich-client apps would<br>
> break if we supported federated login for our consumer users, and in fact<br>
> they do break for the large number of our enterprise E-mail<br>
> outsourcing customers who run their own identity provider, and for which<br>
> Google is a relying party today. This problem with rich-client apps also<br>
> affects other sites like Plaxo who are already relying parties.<o:p></o:p></p>
</div>
<p class=MsoNormal>> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Chris Messina<br>
Citizen-Participant &<br>
Open Technology Advocate-at-Large<br>
<a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a
href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a
href="http://vidoop.com" target="_blank">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ]
private<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>