Hey Josh, Thanks for your message and great points. See my thoughts/questions inline.
On 6/7/07, Josh Hoyt < [EMAIL PROTECTED]> wrote:
On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote: > Over the last few days I've been thinking about your Identifier Recycling > proposal[2], in addition to other proposals (Tokens, etc). Assuming I > understand things correctly, it seems as if a hybrid of the public/private > token approach would seem to garner the most checks, per the IIW grid. Not > sure if my idea is technically correct or not, so please let me know if what > I'm proposing falls short anywhere. Here goes.... I'm not sure I understand what's "public" about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something?
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? This approach was rejected at IIW because:
1. An extra database field is required (whether or not the data is transmitted using attribute exchange)
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?). 2. There is no obvious way to tell if a user is the same user across
sites (The identifier contains a secret portion)
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: <a href=" http://me.example.com#1234";>http://me.example.com</a> 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. 3. Concern about depending on a secret for a user to be able to sign
in to a site (David's Wordpress issue)
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). 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(?) I'm not sure which of these issues were the basis for rejecting this
approach. To me, the biggest problem with it is (2)
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. Maybe the solution is use both approaches at the same time? Josh
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
