[OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0? (IIW session))
Drummond Reed
drummond.reed at cordance.net
Sat May 12 01:07:28 UTC 2007
I'm late in joining this thread, but I would be remiss if I didn't point out
this is one of the advantages of using an XRI as an OpenID. See the point
about persistent identifiers at:
http://dev.inames.net/wiki/XRI_and_OpenID
Having infrastructure automatically map reassignable identifiers to
persistent identifiers really starts to make sense when that identifier
represents the keys to the kingdom. I suspect relatively few OpenID folks
appreciate that this is the purpose of the CanonicalID element in an XRDS
document. See the example below (my own XRDS):
<XRDS ref="xri://=drummond.reed">
<XRD>
<Query>*drummond.reed</Query>
<Status code="100"/>
<Expires>2007-05-12T02:05:27.000Z</Expires>
<ProviderID>xri://=</ProviderID>
<LocalID priority="10">!F83.62B1.44F.2813</LocalID>
<CanonicalID priority="10">=!F83.62B1.44F.2813</CanonicalID>
<Service priority="10">
<Type match="null"/>
<Type select="true">xri://+i-service*(+forwarding)*($v*1.0)</Type>
<ProviderID/>
<Path match="default"/>
<Path select="true">(+index)</Path>
<URI append="qxri" priority="1">http://2idi.com/forwarding/</URI>
</Service>
<Service priority="10">
<Type select="true">http://openid.net/signon/1.0</Type>
<ProviderID/>
<URI append="qxri" priority="2">http://2idi.com/openid/</URI>
<URI append="qxri" priority="1">https://2idi.com/openid/</URI>
</Service>
<Service priority="10">
<Type match="default"/>
<Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
<ProviderID/>
<Path select="true">(+contact)</Path>
<Path match="null"/>
<URI append="qxri" priority="1">http://2idi.com/contact/</URI>
</Service>
</XRD>
</XRDS>
Looking forward to discussing more at IIW next week.
=Drummond
_____
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of John Panzer
Sent: Thursday, May 10, 2007 11:18 PM
To: Dick Hardt
Cc: Martin Atkins; general at openid.net
Subject: Re: [OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0?
(IIW session))
Well, as long as you don't mind being openid.aol.com/dick1138.... :^)
Memorable, human readable, globally unique, and permanent : Pick three
(maybe two).
-John
Dick Hardt wrote:
I've been reflecting on this and I wonder if recycling OpenIDs is a
*good* thing.
I understand the incentive for sites with large user bases to be able
to recycle names.
An OpenID is much more then just a means of proving it is me again at
a website. An OpenID is a URI that is globally unique and that sites
can and *will* attach reputation to. It is also human readable, so
when I see the same OpenID at numerous sites, I expect it to refer to
the same entity. We expect the URI to be consistent over time and space.
Any special treatment such as unique fragment must be preserved as
part of the URL wherever it is used and displayed otherwise there
will be confusion as to who the OpenID refers. I think that once a
URL has been handed out to a user, it is permanent.
Perhaps I am missing something, but I don't see how OpenIDs can be
safely recycled even if there is some mechanism for an RP to know it
is different. We should just make them different.
-- Dick
On 10-May-07, at 7:15 PM, Allen Tom wrote:
Hi Martin,
I believe that adding unique generation identifier (like a nonce,
serial
number, creation timestamp, or just a random blob) in the
Authentication
Response would not necessarily break backwards compatibility with RPs.
Existing OpenID 1.1 RPs can continue to ignore the generation
identifier, however 2.0 RPs should use the OpenID+Generation
Identifier
to recognize users. RPs that are upgrading from 1.1 to 2.0 should
perform a rename operation on their existing users when their existing
users login for the first time after the RP upgrades to 2.0. For
instance, For instance, if an existing user has the OpenID
<http://op.com/user> "http://op.com/user" the account will be renamed
<http://op.com/user#GenID> "http://op.com/
user#GenID <http://op.com/user#GenID> "
This assumes that RPs are able to support user rename operations.
Support of rename operations and linking and unlinking OpenIDs from
accounts are topics that the community needs to address as part of an
OpenID Best Practices document.
The OpenID recycling issue needs to be resolved sooner rather than
later, and solving it in OpenID 2.0 seems to be the right time to
do it.
Allen
Allen Tom wrote:
Issue #2) OpenID recycling
In order to free up desirable userids, many large OPs recycle
userids
belonging to inactive accounts. If an OpenID is recycled, the new
owner
will be able to access the previous owner's data if the RP is not
aware
that the OpenID has changed ownership.
We have actually touched on this issue briefly in the past. One idea
that was floated around was the use of a "serial number"[1] in
addition
to the OpenID URL, where providers would ensure that the same serial
number is not used for two instances of the same identifier. However,
this is troublesome because it requires RPs to change the way they
store
and identify identifiers, and is thus not backward-compatible.
At the moment, OPs should not be recycling usernames at all. Any that
are doing so are broken. That is not to say we should not come up
with a
better approach that allows recycling, however.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070511/62c20665/attachment-0002.htm>
More information about the general
mailing list