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

[Andrew Arnott]

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/20090406/71fb6a6a/attachment.htm>