Nat actually makes a very important point here with regard to the
persistent non-recyclable identifier issue: in order for it to fully
protect the OpenID user, this identifier must be returned to the RP
via the discovery process, not the authentication process. I encourage
folks to read Nat's blog post. Yet another reason why I personally
believe Discovery should be its own independent modular specification
for OpenID v.next.
=Drummond
On Tue, Dec 1, 2009 at 7:09 AM, Nat Sakimura <[email protected]
<mailto:[email protected]>> wrote:
+1 to both Drummond's and Andrew's point.
I have done a blog post a while ago:
http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/
If nothing else, what OpenID v.next should do is to deal with this
problem.
Simply put, the persistent identifier must be returned by the
Discovery Service, not Authentication Service.
Note: This as an impact to the UX of identifer_select, and a way
to cope with it is desired.
On Tue, Dec 1, 2009 at 3:32 PM, Drummond Reed
<[email protected] <mailto:[email protected]>>
wrote:
+1 to all the points Andrew makes for all the security reasons
about why every human-friendly recycleable OpenID identifier
should be paired with a persistent non-recycleable identifier,
and why RPs should use ONLY the latter as the persistent
identifier for the user's account at the RP.
As Andrew says, it's not about users being able to switch
recyclable identifiers - they can do that today. It's about
the huge security hole that opens up when they LOSE CONTROL of
a recyclable identifier - their domain name lapses and is
reassigned, or their URL is reassigned. By the definition of
OpenID, this means the new owner/controlled of that identifier
can now fully and completely impersonate the previous
owner/controller everywhere they had an OpenID account --
without detection or recourse.
Don't misunderstand - I'm not saying OpenID has to adopt XRI
i-names/i-numbers as the only solution to this problem (though
XRI synonym architecture was developed for this very purpose).
Regular URLs and hash-URLs are another option (weaker but
still valid). And still other solutions could be developed.
What I am saying is that unless OpenID v.next builds the
capacity for automatic synonym mapping - from one or more
human-friendly recyclable identifiers to a persistent
non-recyclable identifier, and RPs adopt the practice of
storing the former as the friendly name and the latter as the
persistent external account identifier -- will the problem
truly be solved.
(Note: this solution is othogonal to directed identity - the
persistent non-recyclable identifer can be pairwise-unique or
not depending on the user's privacy preferences - but in the
former case it is of course important not to turn around and
share a non-pairwise unique human-friendly recylable
identifier as a synonym.)
Net net: it's not an easy solution. But it must be tackled if
OpenID is going to grow to the next level.
=Drummond
On Mon, Nov 30, 2009 at 6:15 AM, Andrew Arnott
<[email protected] <mailto:[email protected]>> wrote:
James,
You make a good point about using "=drummond" everyone
eventually leading to out-of-date identifiers. But I
think the biggest value to non-recycleable persistent
identifiers is the security that losing control of that
identifier cannot lead to someone else eventually spoofing
your identity at an RP. That's /huge/.
The second most important value (IMO) of this is that
after "=drummond" is recycled, Drummond can still either
log into the RP with his i-number, or acquire a new
recyclable identifier and attach it to his i-number and
log in with that. I don't know how re-attaching a new
i-name to an existing i-number works, or even if it does
today. But it seems like a logical thing to be able to do.
The convenient, but least important IMO, is what you bring
up, James, which is that others who recognize the i-name
are still able to find the original owner, even if that
owner doesn't own that alias any more. I don't know how
to make this work, but given the two earlier points, I
think achieving the first two without the third would
still be hugely worthwhile.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll
defend to the death your right to say it." - S. G. Tallentyre
On Mon, Nov 30, 2009 at 6:01 AM, Manger, James H
<[email protected]
<mailto:[email protected]>> wrote:
=Drummond,
> In any case, I feel very very strongly that whatever
OpenID v.next does about identifiers,
> it MUST address the issue of consistent handling and
mapping of persistent, non-recycleable identifiers and
> non-persistent, reassignable human-friendly synonyms
for those identifiers.
A “persistent, non-recycleable identifier” (eg an
i-number) sounds like a useful concept, but I am
always struck by how much more useful “=drummond”
seems to be than whatever your i-number happens to be.
“=drummond” (eg an i-name) is supposed to be a
“non-persistent, reassignable synonym” for your
i-number. However, only your i-name appears in e-mails
(like this thread), your blog domain name, web pages,
and other online resources. If =drummond gets
reassigned, these resources will not change so they
become “wrong”. Having an i-number doesn’t seem to
help here.
Perhaps these are aspects of reputation, and perhaps
reputation is a special case that needs human-friendly
i-names not persistent i-numbers.
I guess accounts at online service providers that use
your i-number as the account id will “fail safely” if
your i-name is reassigned. Even in this situation,
though, it is not clear that non-recycleable
identifiers are crucial. You can notify a service when
your identifier changes, which just leaves the
services you didn’t care enough about to notify that
benefit from non-recycleable identifiers.
Finally, if someone has let their non-persistent,
reassignable synonym lapse, are they likely to be able
to (securely) reclaim their persistent,
non-recycleable identifier in the future? How do you
prove you own an i-number (some time after you have
stopped paying for an i-name that used to resolve to
it)? I am not that familiar with i-number practises,
but it sounds like an awkward business problem. Does
the process for re-claiming a non-recycleable
identifier (eg an i-number) become a little-known
backdoor that can undermine the security of systems?
*James Manger*
_______________________________________________
general mailing list
[email protected] <mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
[email protected] <mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-general
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
------------------------------------------------------------------------
_______________________________________________
general mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-general
