The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Johnny Bufu]

On 5-Jun-07, at 8:00 AM, Recordon, David wrote:

> I think the largest concern I have with fragments, or really any
> pair-wise shared secret which can't be renegotiated, is that while it
> solves issues for the large service providers it actually inhibits
> OpenID within the grassroots community.

This concern is definitely something new; I haven't seen it expressed  
before.

> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box.  A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension data, or I'm using an extension
> which stores the fragments in /tmp/ and they get blown away.  I now no
> longer have access to my accounts on all the relying parties I've
> visited.  Now what do I do?

What do you do today, if you forget your slashdot password and  
slashdot didn't implement account recovery? Most (if not all) RPs  
today do implement account recovery - they don't want to loose users,  
and they know users make mistakes and forget passwords.

> We can't count on each RP implementing an account recovery mechanism;
> remember OpenID outsources account management so you can focus on
> building you application.  I can't call up my service provider and ask
> them to fix it, since well I was using my own provider.

You should call up your OP then.

> I could try to
> call up my webhost and see if they can restore from a backup, but I'd
> guess by the time I realize what that check box in my WordPress
> extension settings did there may not even be backups anymore.  In the
> end, I'd be extremely frustrated that OpenID didn't work for me   
> and I'd
> write a really obnoxious blog post about how much OpenID sucks.
>
> So while we solve one aspect of the recycling problem, we end up
> creating a larger problem from the opposite side of the equation.  I'm
> certainly not arguing that we shouldn't solve this problem, nor that
> participation from large providers isn't vital, but would hate to  
> see us
> create a problem for all of the people out there that have really  
> helped
> gain OpenID traction.
>
> I don't want to say that I have the answers here, since I don't  
> think I
> do.  I do however see the following possible solutions:
>
> 1) The core specification only talks about fragments in relation to
> Relying Parties, to the extent that they should be stripped from  
> display
> though used as a unique key.  We do however need to address how a RP
> should handle display and account management differences when a  
> fragment
> changes.  I'm guessing it is unreasonable to expect every instance of
> https://davidrecordon.com to be replaced with
> https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
> to mention that the fragment *must* remain private between the OP  
> and RP
> to be effective).  An extension is then written describing fragment
> usage from the OP perspective with huge warnings about how it should
> only be used by large service providers who know what they're doing.

I believe it could work with REQUIREments in the core for RPs  
(discovery, verification), and OPTIONAL / extension for the OPs.  
Though the gained simplicity I think would be minimal. But if the  
other advantage is that OPs don't carelessly implement this feature  
without knowing what they are doing, then it may be better overall.

Totally agree with the warnings / raising awareness that identifier  
recycling is an advanced feature. I believe this is part of a more  
general problem: by being decentralized, OpenID gives power to  
everyone (anyone can be an OP); while being an RP is / should be  
simple, doing the OP job right is not.

> 2) We use a centralized "canonical id" approach like i-numbers.
> Basically somebody issues unique and never reassigned ids.
>
> 3) We use a distributed "canonical id" approach.  Providers issue an
> ugly non-reassignable URL which points at the pretty one and vice- 
> versa.
> Thus https://davidrecordon.com says its canonical is
> https://12jbd9210.pip.verisignlabs.com which in turn says it is
> https://davidrecordon.com.  We could even kill two birds with one  
> stone
> and use "<link rel='me' />" to do this and setup an easy way to create
> identifier equality.

> I think my preference is #3, though I'm sure it has its own issues.

Do you have a more detailed proposal on how this would work? I do see  
a couple important / possibly show-stopper issues here, but I haven't  
really explored this direction for a solution. If you have, I would  
definitely be interested to learn more.

However, I still believe #1 is our best bet, if we can focus our  
efforts to make it work in such a way to address your grassroots  
adoption concerns. #1 did have (and still has, I hope) the support of  
a good many people, and has a concrete and detailed proposal. If we  
agree that _some_ changes to the core are required, then #1 has also  
the time advantage.


> 4) We use public/private key pairs, though this has the traditional
> private key revocation issues.


Johnny