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 <andrewarn...@gmail.com > <mailto:andrewarn...@gmail.com>> 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
