Hey Josh,<br><br>Thanks for your message and great points. See my thoughts/questions inline.<br><br><div><span class="gmail_quote">On 6/7/07, <b class="gmail_sendername">Josh Hoyt</b> <<a href="mailto:josh@janrain.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
josh@janrain.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/7/07, David Fuelling <<a href="mailto:sappenin@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sappenin@gmail.com</a>> wrote:<br>> Over the last few days I've been thinking about your Identifier Recycling
<br>> proposal[2], in addition to other proposals (Tokens, etc). Assuming I
<br>> understand things correctly, it seems as if a hybrid of the public/private<br>> token approach would seem to garner the most checks, per the IIW grid. Not<br>> sure if my idea is technically correct or not, so please let me know if what
<br>> I'm proposing falls short anywhere. Here goes....<br><br>I'm not sure I understand what's "public" about this. If I understand<br>it correctly, from the relying party's perspective, the user's account
<br>is keyed off of the pair of the identifier and the token. This sounds<br>like URL + private token in that table. Am I missing something?</blockquote><div><br>Maybe I don't understand the difference between private and public tokens. My proposal used private information to create a public token that can be sent via AX (thus the hybrid term). Am I understanding the difference between private/public tokens incorrectly?
<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This approach was rejected at IIW because:<br><br> 1. An extra database field is required (whether or not the data is
<br>transmitted using attribute exchange)</blockquote><div><br>If the AX database schema is architected properly, then the
addition of a new AX attribute should not necessitate a new database
column. If this were the case, then AX would not really be feasible (how would an RP deal with a new AX attribute?).<br>
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2. There is no obvious way to tell if a user is the same user across<br>sites (The identifier contains a secret portion)
</blockquote><div><br>Good point. Although, let's assume that RP's display fragment-enabled OpenID's in the following manner, which overcomes the "Fragments are Ugly" problem:<br><a href="<a href="http://me.example.com#1234" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://me.example.com#1234</a>"><a href="http://me.example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://me.example.com</a></a><br><br>Users will not be able to easily distinguish that the OpenID is owned by a different user without hovering over the URL in their browser. That said, computers will be able to, since the actual HREF is what counts, I assume. Has this been discussed wrt to fragments.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3. Concern about depending on a secret for a user to be able to sign
<br>in to a site (David's Wordpress issue)</blockquote><div><br>I think DR had a problem with anything that could be lost, thereby preventing access to an RP. Both Fragments and Tokens seem to suffer from this problem, since in the Fragment scheme, if I or my OP forgets what my fragment was, I won't be able to login to an RP without recycling my account (or forcing an account recovery procedure).
<br><br>Seems like the odds of my OP losing my fragment information are pretty slim. Identically, the odds of my OP losing my recycling_password are pretty slim, too. What's more, If *I* lose my recycling password, why should I care? Only the OP needs to deal with it, and perhaps the OP can just show me that password in an account settings page when I login(?)
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not sure which of these issues were the basis for rejecting this<br>approach. To me, the biggest problem with it is (2)</blockquote><div><br>I agree that #2 is a problem with the token approach. However, the fragment approach doesn't solve the problem of a new OP domain owner being able to make auth assertions for OpenID's that were created for a previous owner (See my proposal #3). This seems to be an edge case, but its effects are much more devastating than people not being able to visually (or otherwise) determine who owns a given OpenID.
<br><br>Maybe the solution is use both approaches at the same time?<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Josh<br></blockquote>
</div><br>