<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yahoo does recycle email addresses, so the OpenID URL (including the
#fragment) must be used to identify the user. <br>
<br>
Yahoo allows users to create customized OpenIDs, and the customized
portion of the URL can be recycled. However, the #fragment portion
represents a unique generation identifier, so RPs should consider the
entire OpenID URL returned in assertion to identify the user.<br>
<br>
See section 11.15.1 (Identifier Recycling) of the OpenID 2.0 spec for
more info:<br>
<a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-authentication-2_0.html#identifying">http://openid.net/specs/openid-authentication-2_0.html#identifying</a><br>
<br>
Allen<br>
<br>
<br>
Eric Sachs wrote:
<blockquote
cite="mid:c4161f510811050903n60f2ffcfha26237c0d4284b4a@mail.gmail.com"
type="cite">
<div>In the case of Google (and I believe Yahoo), we return a
persistent machine generated identifier (in the form of a URL) to
identify a particular Gmail account. Even if that person changes their
Gmail address, that ID stays unchanged. So our documentation suggests
that RPs should use the URL as the persistent identifier, not the
E-mail address we return via AX. Gmail does not yet recycle e-mail
addresses, but I believe Yahoo does, and I think they also suggest
using the machine generated ID/URL as the persistent identifier.</div>
<br>
<div class="gmail_quote">On Wed, Nov 5, 2008 at 4:05 AM, Kick
Willemse <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:K.Willemse@diginotar.nl">K.Willemse@diginotar.nl</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="NL">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">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?</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">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)</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">Kick</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">-------------------------------------------------------------------------------------</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">Kick Willemse</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">Product Manager</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">e-mail: </span><span
style="font-size: 11pt; color: rgb(31, 73, 125);"><a
moz-do-not-send="true" href="http://k.willemse@diginotar.nl"
target="_blank"><span style="color: blue;" lang="EN-US">k.willemse@diginotar.nl</span></a></span><span
style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">weblog: </span><span
style="font-size: 11pt; color: rgb(31, 73, 125);"><a
moz-do-not-send="true" href="http://www.papierloos.nl/" target="_blank"><span
style="color: blue;" lang="EN-US">http://www.papierloos.nl</span></a></span><span
style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">DigiNotar
B.V.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Vondellaan
8</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">1942LJ
Beverwijk</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">telefoon:
0251-268888</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
</div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
<p><b><span style="font-size: 10pt;">Van:</span></b><span
style="font-size: 10pt;">
<a moz-do-not-send="true" href="mailto:general-bounces@openid.net"
target="_blank">general-bounces@openid.net</a> [mailto:<a
moz-do-not-send="true" href="mailto:general-bounces@openid.net"
target="_blank">general-bounces@openid.net</a>] <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> <a moz-do-not-send="true"
href="mailto:oauth@googlegroups.com" target="_blank">oauth@googlegroups.com</a>;
'OpenID user experience'; 'OpenID List'<br>
<b>Onderwerp:</b> Re: [OpenID] Google Removes Relying Party
Pre-Registration</span></p>
</div>
</div>
<p> </p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">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?</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">I haven't thought through all the detail, just wanted to
see if
anyone had considered this technique?</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US">steven</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"><a moz-do-not-send="true" href="http://livz.org"
target="_blank">http://livz.org</a></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<p><span lang="EN-US"><a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Security_token" target="_blank">http://en.wikipedia.org/wiki/Security_token</a></span><span
style="font-size: 11pt; color: rgb(31, 73, 125);" lang="EN-US"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"
lang="EN-US"> </span></p>
<div
style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
<p><b><span style="font-size: 10pt;" lang="EN-US">From:</span></b><span
style="font-size: 10pt;" lang="EN-US"> <a moz-do-not-send="true"
href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[mailto:<a moz-do-not-send="true"
href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>]
<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> <a moz-do-not-send="true"
href="mailto:oauth@googlegroups.com" target="_blank">oauth@googlegroups.com</a>;
OpenID user experience; OpenID List<br>
<b>Subject:</b> Re: [OpenID] Google Removes Relying Party
Pre-Registration</span></p>
</div>
<p><span lang="EN-US"> </span></p>
<div>
<p><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:</span></p>
</div>
<div>
<p><span lang="EN-US"> </span></p>
</div>
<div>
<p><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.</span></p>
</div>
<div>
<p><span lang="EN-US"> </span></p>
</div>
<div>
<p><span lang="EN-US">We have considered an approach along the
lines of what you described. In particular, s</span><span><span
lang="EN-US">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"></span></p>
</div>
<div>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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>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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">For
Google, in the "fridge display private photos"
example, our team had suggested something like the following </span><span
lang="EN-US"> </span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">7) The
user click's the continue button on the device/app</span><span
lang="EN-US"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">8) The
device/app then finishes the OAuth dance</span><span lang="EN-US"></span></p>
<p><span style="font-size: 10pt; color: black;" lang="EN-US">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"></span></p>
</div>
<p style="margin-bottom: 12pt;"><span lang="EN-US"> </span></p>
<div>
<p><span lang="EN-US">On Thu, Oct 30, 2008 at 4:32 PM, Chris
Messina <<a moz-do-not-send="true"
href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>>
wrote:</span></p>
<p><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 moz-do-not-send="true"
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</span></p>
<div>
<p style="margin-bottom: 12pt;"><span lang="EN-US"><br>
On Fri, Oct 31, 2008 at 7:20 AM, David Recordon <<a
moz-do-not-send="true" href="mailto:drecordon@sixapart.com"
target="_blank">drecordon@sixapart.com</a>>
wrote:<br>
> From<br>
> <a moz-do-not-send="true"
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</span></p>
</div>
<div>
<p><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.</span></p>
</div>
<p><span lang="EN-US">>
_______________________________________________<br>
> general mailing list<br>
> <a moz-do-not-send="true" href="mailto:general@openid.net"
target="_blank">general@openid.net</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true" href="http://factoryjoe.com"
target="_blank">factoryjoe.com</a> # <a moz-do-not-send="true"
href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a moz-do-not-send="true" href="http://citizenagency.com"
target="_blank">citizenagency.com</a> # <a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:general@openid.net"
target="_blank">general@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></span></p>
</div>
<p><span lang="EN-US"> </span></p>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</body>
</html>