[OpenID] persistent, non-recycleable identifiers

George Fletcher gffletch at aol.com
Tue Dec 1 20:38:54 UTC 2009


I'm all in favor of solving the delegation use case and associated 
identifier "nightmares" it creates for RPs:)

However, if I understood Nat's blog correctly, the proposed solution is 
to delegate the "persistent" identifier mapping to a Discovery service. 
Now the user has to either run one of these, with it's related issues of 
SSL, trust, security, signing, etc or it has to choose a Discovery 
service provided by someone else. If the latter, then I don't see much 
difference from what we have today? That chosen Discovery service can go 
out of business and the user is still stuck. We've just moved the 
problem with another level of indirection.

Questions that come to mind...

1. Since the XRD can be static, how is the Canonical ID generated? Who's 
authoritative?
2. Can I the user generate a long random string and claim it's my 
canonical ID?
    * Can I steal someone else's CanonicalD and stick it in my XRD? (if 
self-signed?)
3. Is the CanonicalID space global? or scoped to the Discovery service I 
choose?
4. For pair-wise pseudonymous, I assume the RP must specify some 
identifier to the Discovery service so it knows what value to return?
5. If the user generates it themselves, then how is an "opaque" or 
"persistent" identifier any better than the current delegation model 
that forces an RP to "trust" whatever the user types in as the key? Both 
are specified by the user. I suppose with a signed XRD a few of the 
redirect based security holes are closed.

Don't get me wrong. I'd love to get to a solution for these issues. 
Being an RP and trying to support delegation as it currently stands is 
very painful. Either you expose the user to security risks, or you break 
the experience:(

Thanks,
George

Drummond Reed wrote:
> 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 <sakimura at gmail.com 
> <mailto:sakimura at gmail.com>> 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
>     <drummond.reed at cordance.net <mailto:drummond.reed at cordance.net>>
>     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
>         <andrewarnott at gmail.com <mailto:andrewarnott at gmail.com>> 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
>             <James.H.Manger at team.telstra.com
>             <mailto:James.H.Manger at team.telstra.com>> 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
>                 general at lists.openid.net <mailto:general at lists.openid.net>
>                 http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
>         _______________________________________________
>         general mailing list
>         general at lists.openid.net <mailto:general at lists.openid.net>
>         http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>     http://www.sakimura.org/en/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>   



More information about the specs mailing list