[OpenID] [oauth] Re: Replacing email verification with RSS 'push' feeds and OAuth
andrewarnott at gmail.com
Tue Apr 7 03:11:49 UTC 2009
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.
"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 <paul.madsen at gmail.com> 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)?
> 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 <andrewarnott at 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
>> - 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
> You received this message because you are subscribed to the Google Groups
> "OAuth" group.
> To post to this group, send email to oauth at googlegroups.com
> To unsubscribe from this group, send email to
> oauth+unsubscribe at googlegroups.com <oauth%2Bunsubscribe at googlegroups.com>
> For more options, visit this group at
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general