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.

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?

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.  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.

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.

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

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


-----Original Message-----
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 03, 2007 6:35 PM
To: Recordon, David
Cc: Johannes Ernst; OpenID specs list
Subject: Re: Specifying identifier recycling

On 3-Jun-07, at 1:46 AM, Recordon, David wrote:

> I thought at IIW we agreed that if we could come to quick consensus  
> on a
> way to resolve the problem it would be a part of 2.0, otherwise it  
> would
> not...

Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on  
how to solve this issue. But the issue was deemed important enough to  
be one of the only two on the 2.0 agenda.

> As concerns with the fragment proposal have been raised, which had the
> most agreement at IIW, it seems we no longer have consensus.

I haven't seen many actually; checking this thread for what can count  
as concerns reveals only:
a) Josh's initial email
b) Johannes' +1 to not adopting a solution that doesn't actually work
c) David acknowledging the concerns

This doesn't seem to me to carry enough weight to veto the fragment  
proposal, especially when a) has been / can still be addressed, and  
the fragment proposal made sense to a dozen people at that meeting.

> As seen in
> this thread, there are a wide variety of opinions as to how to resolve
> this concern.  I thus think merely picking one for the sake of putting
> something into 2.0 would be misguided.

True, there have been a few (I definitely wouldn't call it a wide  
variety) possible solutions mentioned, but none very well defined,  
and none had the support of 10+ people like the fragment did.

I have argued that it will have to be core (whether 2.0 or 3.0). I  
guess we should ask ourselves then if we really want this addressed  
in 2.0, and if yes then try to make it work.

So I ask again - does anyone see any issues with the fragments being  
used like this:


If not, I have a hard time understanding where exactly the consensus  
was lost.


specs mailing list

Reply via email to