Questions about IIW Identifier Recycling Table

David Fuelling sappenin at gmail.com
Fri Jun 8 00:49:19 UTC 2007


Hey Josh,

Thanks for your message and great points.  See my thoughts/questions inline.

On 6/7/07, Josh Hoyt < josh at janrain.com> wrote:
>
> On 6/7/07, David Fuelling <sappenin at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070607/c765809c/attachment-0002.htm>


More information about the specs mailing list