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. <div>
<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Mon, Apr 6, 2009 at 12:42 PM, Paul Madsen <span dir="ltr"><<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
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)?<br>
<br>
paul<div><div></div><div class="h5"><br>
<br>
Andrew Arnott wrote:
<blockquote type="cite">One more benefit of this system:
<div>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.</div>
<div><br>
</div>
<div>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.<br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire<br>
<br>
<br>
<div class="gmail_quote">On Mon, Apr 6, 2009 at 8:45 AM, Andrew
Arnott <span dir="ltr"><<a href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">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 <b>get some feedback from you</b>.
<div><br>
</div>
<div>First the problems:</div>
<div>
<ul>
<li>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.</li>
<li>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).</li>
<li>Email verification is a blocker to account registration for
many would-be users. </li>
<li>RPs can't <i>generally</i> rely on OPs' assertions of a
user's email address because the OP could be controlled by the user.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>Configuring web sites to send email can be difficult,
particularly when their service provider disallows SMTP.</li>
</ul>
<div>Proposed solution:</div>
<div>
<ol>
<li>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.</li>
<li>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".</li>
<li>The user is now logged into the RP.</li>
</ol>
When the RP wants to send messages to the user, it POSTs to the queuing
SP using its OAuth token.</div>
<div>The user receives these messages in a manner previously
configured with his queuing SP, which will typically be via email
forwarding to his inbox.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>Open issues / questions:</div>
<div>
<ol>
<li>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.</li>
<li>A standardized message push POST format will have to be
spec'd out.</li>
</ol>
</div>
<div><br>
</div>
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<br>
</blockquote>
<br>
</div></div><font color="#888888"><pre cols="72">--
Paul Madsen e:paul.madsen @ <a href="http://gmail.com" target="_blank">gmail.com</a>
m:613-282-8647
web:<a href="http://connectid.blogspot.com" target="_blank">connectid.blogspot.com</a> </pre></font><div class="im">
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups "OAuth" group. <br> To post to this group, send email to <a href="mailto:oauth@googlegroups.com" target="_blank">oauth@googlegroups.com</a> <br>
To unsubscribe from this group, send email to <a href="mailto:oauth%2Bunsubscribe@googlegroups.com" target="_blank">oauth+unsubscribe@googlegroups.com</a> <br> For more options, visit this group at <a href="http://groups.google.com/group/oauth?hl=en" target="_blank">http://groups.google.com/group/oauth?hl=en</a><br>
-~----------~----~----~----~------~----~------~--~---<br>
</div></div>
<br>
</blockquote></div><br></div>