[OpenID] [oauth] Re: Replacing email verification with RSS 'push' feeds and OAuth

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.
--
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 <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)?
>
> 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 <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
>>    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 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
> http://groups.google.com/group/oauth?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090406/be3f8908/attachment.htm>