<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" 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.E-mailStijl19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.E-mailStijl20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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=NL link=blue vlink=purple>
<div class=Section1>
<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'><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>With the developments evolving to e-mail adress as the OpenID- userID,
I would like to know if anybody is aware of any regulations around the (re)issuing
of mailboxes bij ISP’s or Mail Service Providers.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So what is the risk if I cancel my gmail or hotmail account and
this adres is re-issued to somebody else that subsequently can use this same
openID?<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I wonder if the risk as described is a non-issue or if any
conclusions around this topic are already available. Not only the risk during a
authentication, but also from an audittrail perspective (Who authenticated last
year)<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Kick<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Kick Willemse<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Product Manager<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>e-mail: </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><a href="k.willemse@diginotar.nl"><span lang=EN-US
style='color:blue'>k.willemse@diginotar.nl</span></a></span><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>weblog: </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><a href="http://www.papierloos.nl/"><span lang=EN-US
style='color:blue'>http://www.papierloos.nl</span></a></span><span lang=EN-US
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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'>DigiNotar B.V.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vondellaan 8<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>1942LJ Beverwijk<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>telefoon: 0251-268888<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<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"'>Van:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>Namens </b>Steven
Livingstone-Perez<br>
<b>Verzonden:</b> woensdag 5 november 2008 11:38<br>
<b>Aan:</b> 'Eric Sachs'; 'Chris Messina'<br>
<b>CC:</b> oauth@googlegroups.com; 'OpenID user experience'; 'OpenID List'<br>
<b>Onderwerp:</b> Re: [OpenID] Google Removes Relying Party Pre-Registration<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span lang=EN-US 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 lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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 lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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 lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>steven<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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 lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US><a
href="http://en.wikipedia.org/wiki/Security_token">http://en.wikipedia.org/wiki/Security_token</a></span><span
lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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 lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US 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><span lang=EN-US><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US>>> 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></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>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></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>We have considered an approach along the
lines of what you described. In particular, s</span><span
class=apple-style-span><span lang=EN-US 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><span
lang=EN-US><o:p></o:p></span></p>
</div>
<div>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US 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><span
lang=EN-US> <o:p></o:p></span></p>
<p><span lang=EN-US 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><span
lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span
lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span
lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span
lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>8) The device/app then finishes the OAuth dance</span><span
lang=EN-US><o:p></o:p></span></p>
<p><span lang=EN-US 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><span lang=EN-US><o:p></o:p></span></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><span lang=EN-US>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></span></p>
<p class=MsoNormal><span lang=EN-US>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></span></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US><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></span></p>
</div>
<div>
<p class=MsoNormal><span lang=EN-US>> 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></span></p>
</div>
<p class=MsoNormal><span lang=EN-US>>
_______________________________________________<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></span></p>
</div>
<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>
</div>
</body>
</html>