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
> proposal[2], in addition to other proposals (Tokens, etc).  Assuming I
> understand things correctly, it seems as if a hybrid of the
> 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
> 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"
<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?


specs mailing list

Reply via email to