<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:1147476222;
        mso-list-template-ids:288406442;}
@list l1
        {mso-list-id:1566256649;
        mso-list-template-ids:-1945061626;}
@list l2
        {mso-list-id:1608655508;
        mso-list-template-ids:2066764622;}
@list l2:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Once there is a direct channel between user and RP (that is not
mediated by an OP), one can build on the tokens to create secure messaging &#8211;
in much the same way that WS-SX builds on Security Token exchange to create a
layer7-layer SSL-like handshake and two simplex associations in the WCF world.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Once one has associations, the user as OP or vanity site becomes
more viable &#8211; as we now know that openid can leverage such an OOB
association to share its master keying.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Andrew
Arnott<br>
<b>Sent:</b> Monday, April 06, 2009 11:04 AM<br>
<b>To:</b> general; oauth@googlegroups.com<br>
<b>Subject:</b> Re: [OpenID] Replacing email verification with RSS 'push' feeds
and OAuth<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>One more benefit of this system:&nbsp;<o:p></o:p></p>

<div>

<p class=MsoNormal>The RP has no idea who you are (unless you tell it by other
means). &nbsp;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. &nbsp;Thus, the RP cannot correlate users, and can only ensure
that message goes to the right user. &nbsp;Privacy is built up this way.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>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>
&quot;I [may] not agree with what you have to say, but I'll defend to the death
your right to say it.&quot; - Voltaire<br>
<br>
<o:p></o:p></p>

<div>

<p class=MsoNormal>On Mon, Apr 6, 2009 at 8:45 AM, Andrew Arnott &lt;<a
href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>&gt; wrote:<o:p></o:p></p>

<p class=MsoNormal>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>.<o:p></o:p></p>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>First the problems:<o:p></o:p></p>

</div>

<div>

<ul type=disc>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>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.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>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).<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>Email verification is a blocker to account
     registration for many would-be users. &nbsp;<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>RPs can't&nbsp;<i>generally</i>&nbsp;rely on OPs'
     assertions of a user's email address because the OP could be controlled by
     the user.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>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.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>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 &quot;noreply&quot; email address.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>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.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l2 level1 lfo1'>Configuring web sites to send email can be
     difficult, particularly when their service provider disallows SMTP.<o:p></o:p></li>
</ul>

<div>

<p class=MsoNormal>Proposed solution:<o:p></o:p></p>

</div>

<div>

<ol start=1 type=1>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo2'>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. &nbsp;This element also
     includes information the RP needs to use OAuth for authorization to send
     to this message queue.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo2'>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. &nbsp;The user is directed to a web page
     explaining the RP wants to send messages and clicks &quot;Accept&quot;.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l1 level1 lfo2'>The user is now logged into the RP.<o:p></o:p></li>
</ol>

<p class=MsoNormal>When the RP wants to send messages to the user, it POSTs to
the queuing SP using its OAuth token.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>The user receives these messages in a manner previously
configured with his queuing SP, which will typically be via email forwarding to
his inbox.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>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.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>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.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>Open issues / questions:<o:p></o:p></p>

</div>

<div>

<ol start=1 type=1>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo3'>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.<o:p></o:p></li>
 <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
     mso-list:l0 level1 lfo3'>A standardized message push POST format will have
     to be spec'd out.<o:p></o:p></li>
</ol>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=MsoNormal>--<br>
Andrew Arnott<br>
&quot;I [may] not agree with what you have to say, but I'll defend to the death
your right to say it.&quot; - Voltaire<o:p></o:p></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>