That depends, Paul. Yes, it certainly means that multiple RPs can't correlate a user's activities. But if I visit the site once, establish a relationship and then terminate it by revoking my OAuth token, and then visit that site again and re-establish its ability to contact me, a new OAuth token will be assigned, and the site may never know that I'm the same person as was there previously. But certainly over time with a single account it can accumulate data on me. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
On Mon, Apr 6, 2009 at 12:42 PM, Paul Madsen <[email protected]> wrote: > Andrew, I assume you mean that with this model multiple RPs can't > correlate the user's activities (or at least not trivially), and not that a > single RP can't correlate the user's activities (over time)? > > paul > > > Andrew Arnott wrote: > > One more benefit of this system: The RP has no idea who you are (unless > you tell it by other means). It can push messages to the user by POSTing to > an SP's URL that is the same for all users, and the SP only knows which user > is the recipient by the OAuth token. Thus, the RP cannot correlate users, > and can only ensure that message goes to the right user. Privacy is built > up this way. > > It also provides an account recovery mechanism because the RP can push a > message to the user with some secret passphrase the user can use later on in > case the OP goes belly-up or cancels the user's account. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - Voltaire > > > On Mon, Apr 6, 2009 at 8:45 AM, Andrew Arnott <[email protected]>wrote: > >> Deep in another OpeNID thread I suggested part of this idea, but I've >> expanded on that idea in my head and think it deserves its own thread >> besides to *get some feedback from you*. >> First the problems: >> >> - Email verification is a step many web sites have to take the user >> through in order to make sure they can reach the user, to allow an account >> recovery step later on, and as a sort-of attempt to make sure they're not >> a >> bot, although that's not so reliable. >> - Email verification does not prove to the web site that the email >> address is frequently checked by the user, or even owned by the user (it >> could be an anonymous email service). >> - Email verification is a blocker to account registration for many >> would-be users. >> - RPs can't *generally* rely on OPs' assertions of a user's email >> address because the OP could be controlled by the user. >> - Users giving their personal or work email addresses to web sites, >> especially ones they are not planning on a long-term relationship with, >> contributes to the spam problem. >> - The paradigm of using email to carry on a two-way communication >> doesn't fit very well as many web sites are only interested in pushing >> messages to you from a "noreply" email address. >> - Web sites have a difficult time knowing when their emails are going >> to your spam folder, or when the email address has been deactivated or >> abandoned. >> - Configuring web sites to send email can be difficult, particularly >> when their service provider disallows SMTP. >> >> Proposed solution: >> >> 1. When a user logs into an RP using an OpenID, the RP performs >> discovery on the user's XRDS document and discovers a service element for >> push notifications that includes the URI to receive the messages the RP >> wishes to send to the user. This element also includes information the RP >> needs to use OAuth for authorization to send to this message queue. >> 2. During authentication (if the OP is also providing the message >> queue service for the user) or immediately following authentication (if >> the >> user is using a separate message queuing service), the RP sends an OAuth >> message to the queuing SP requesting authorization to post messages to >> this >> user. The user is directed to a web page explaining the RP wants to send >> messages and clicks "Accept". >> 3. The user is now logged into the RP. >> >> When the RP wants to send messages to the user, it POSTs to the queuing SP >> using its OAuth token. >> The user receives these messages in a manner previously configured with >> his queuing SP, which will typically be via email forwarding to his inbox. >> If the user ever wants to terminate all messages from this RP, he can >> force this by revoking the OAuth token issued to the RP by visiting his >> queuing SP. >> The RP realizes its messaging push permission has been revoked by the 401 >> Unauthorized HTTP response it receives the next time it tries to post a >> message and can then deactivate that account to save bandwidth and >> processing power. >> >> Open issues / questions: >> >> 1. The RP will need a consumer key to send the OAuth request, but it >> often won't have one since any user with any queuing SP may log in. >> 2. A standardized message push POST format will have to be spec'd out. >> >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - Voltaire >> > > > > > -- > Paul Madsen e:paul.madsen @ gmail.com > m:613-282-8647 > web:connectid.blogspot.com > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
