The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)

[=drummond.reed]

David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence is the main use case for it).

I'm happy to help with the writeup -- I've already spent a not-insignificant
portion of my lifespan dealing with this issue ;-)

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Recordon, David
Sent: Tuesday, June 05, 2007 3:50 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: The "WordPress" User Problem (WAS: RE: Specifying
identifierrecycling)

At that point I'd be concerned as to solving the "big OP issue" while
not solving the "lost domain issue" when some of the proposals could
possible solve both.  This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another "ugly" URL
which points back at the pretty one.  I know I need to write this up
more...

--David

-----Original Message-----
From: Johnny Bufu [mailto:johnny at sxip.com] 
Sent: Tuesday, June 05, 2007 3:18 PM
To: Recordon, David
Cc: Josh Hoyt; Johannes Ernst; OpenID specs list
Subject: Re: The "WordPress" User Problem (WAS: RE: Specifying
identifier recycling)

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
> The relying parties SHOULD make the fragment available to software 
> agents, at least, so that it's possible to compare identifiers across 
> sites. If the fragment is never available, then there is confusion 
> about which user of an identifier is responsible for content that has 
> been posted. One use case where software agents having access to the 
> fragment is particularly important is if the identifier is used for 
> access control, and the access control list is retrieved from off-site

> (e.g. from a social networking site).
>
> The implementation that seems most sane is for places that display the

> identifier for human reading look like:
>
> <a href="http://josh.example.com/#this-is-intended-for-machine-
> consumption"
>  >http://josh.example.com/</a>
>
> so that the software agent would see the fragment, but the user 
> wouldn't have to.

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

> I thought the fragment was to be secret so that for the case of using 
> a personal domain you don't have to own joshhoyt.com forever.  Rather 
> as long as your fragments are secret, someone else can buy 
> joshhoyt.com and not be you.  If this is no longer a requirement then 
> it certainly changes the game, though also doesn't solve one of the 
> other aspects of identifier recycling.

I thought so too, but I believe Josh is right - the "lost domain"  
cell with an X in it (for URL + public fragment) supports Josh's
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually simpler
to address just the identifier recycling for big OPs, where loosing the
domain is not an issue.


Johnny

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