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

Jonathan Coffman jonathan.coffman at gmail.com
Tue Apr 7 23:22:11 UTC 2009


As much as I love this idea, and see a LOT of potential for such a thing ‹
it feels like something that might start out as a web service as opposed to
a standard?


On 4/6/09 11:11 PM, "Andrew Arnott" <andrewarnott at gmail.com> wrote:

> 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
>>>>  
>>>>  
>>>  
>>>  
>>>  
>>>  
>>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090407/9e13d8dd/attachment.htm>


More information about the general mailing list