Comments inline... Andrew Arnott 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. > I like this idea, thought it will take some time to "roll out". As you've pointed out, it's critical to RPs to have a way to message their users. To really make this work, the deployment of these "push message queues" has to be as wide spread as email. Otherwise, the RPs will always just migrate to the lowest common denominator. > 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. > I think this is a generic problem and can be solved orthogonally to your idea. > > 1. A standardized message push POST format will have to be spec'd out. > Couldn't we use the "activity streams" spec for this? I like the concept of keeping these "post" messages short, though if this just turns into RPs sending links for the user to click we might be training bad user behavior.
Thanks, George --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
