I'm confused as to why a RP having to not create a new DB field is a
requirement when looking to solve this problem.  RP's implementations
already need to change to upgrade from 1.1 to 2.0 and this has never
been a requirement in the past.  It certainly is nice that storage
changes wouldn't be needed, but I don't see it as something that should
be a requirement.

Can someone shed some light on this for me?

Thanks,
--David

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, June 07, 2007 5:03 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: Questions about IIW Identifier Recycling Table

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?

This approach was rejected at IIW because:

 1. An extra database field is required (whether or not the data is
transmitted using attribute exchange)

 2. There is no obvious way to tell if a user is the same user across
sites (The identifier contains a secret portion)

 3. Concern about depending on a secret for a user to be able to sign
in to a site (David's Wordpress issue)

I'm not sure which of these issues were the basis for rejecting this
approach. To me, the biggest problem with it is (2)

Josh
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to