[OpenID] Persistence of e-mail accounts
Allen Tom
atom at yahoo-inc.com
Fri Nov 7 03:55:27 UTC 2008
Yahoo does recycle email addresses, so the OpenID URL (including the
#fragment) must be used to identify the user.
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.
See section 11.15.1 (Identifier Recycling) of the OpenID 2.0 spec for
more info:
http://openid.net/specs/openid-authentication-2_0.html#identifying
Allen
Eric Sachs wrote:
> 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.
>
> On Wed, Nov 5, 2008 at 4:05 AM, Kick Willemse <K.Willemse at diginotar.nl
> <mailto:K.Willemse at diginotar.nl>> wrote:
>
>
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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)
>
>
>
> Kick
>
>
>
>
>
> -------------------------------------------------------------------------------------
>
> Kick Willemse
>
> Product Manager
>
> e-mail: k.willemse at diginotar.nl <http://k.willemse@diginotar.nl>
>
> weblog: http://www.papierloos.nl <http://www.papierloos.nl/>
>
>
>
> DigiNotar B.V.
>
> Vondellaan 8
>
> 1942LJ Beverwijk
>
> telefoon: 0251-268888
>
>
>
>
>
> *Van:* general-bounces at openid.net
> <mailto:general-bounces at openid.net>
> [mailto:general-bounces at openid.net
> <mailto:general-bounces at openid.net>] *Namens *Steven Livingstone-Perez
> *Verzonden:* woensdag 5 november 2008 11:38
> *Aan:* 'Eric Sachs'; 'Chris Messina'
> *CC:* oauth at googlegroups.com <mailto:oauth at googlegroups.com>;
> 'OpenID user experience'; 'OpenID List'
> *Onderwerp:* Re: [OpenID] Google Removes Relying Party
> Pre-Registration
>
>
>
> 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?
>
>
>
> 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 **if** 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.
>
>
>
> I haven't thought through all the detail, just wanted to see if
> anyone had considered this technique?
>
>
>
> steven
>
> http://livz.org
>
>
>
> http://en.wikipedia.org/wiki/Security_token
>
>
>
> *From:* general-bounces at openid.net
> <mailto:general-bounces at openid.net>
> [mailto:general-bounces at openid.net
> <mailto:general-bounces at openid.net>] *On Behalf Of *Eric Sachs
> *Sent:* 05 November 2008 00:12
> *To:* Chris Messina
> *Cc:* oauth at googlegroups.com <mailto:oauth at googlegroups.com>;
> OpenID user experience; OpenID List
> *Subject:* Re: [OpenID] Google Removes Relying Party Pre-Registration
>
>
>
> >> 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 <mailto: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 <mailto: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 <mailto:general at openid.net>
> > http://openid.net/mailman/listinfo/general
> >
> >
>
>
>
> --
> Chris Messina
> Citizen-Participant &
> Open Technology Advocate-at-Large
> factoryjoe.com <http://factoryjoe.com> # diso-project.org
> <http://diso-project.org>
> citizenagency.com <http://citizenagency.com> # vidoop.com
> <http://vidoop.com>
> This email is: [ ] bloggable [X] ask first [ ] private
> _______________________________________________
> general mailing list
> general at openid.net <mailto:general at openid.net>
> http://openid.net/mailman/listinfo/general
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20081106/52fd72d3/attachment-0002.htm>
More information about the general
mailing list