Shade, Great thoughts! One thing I kept thinking about is how, even if OpenID v.next *doesn't* use PKI is the whole notion of OP multi-auth can work well to help improve security. I started some early draft-spec work on this idea ((https://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html -- there was a lot of great feedback on changes that I just didn't have time to integrate into a new document). Anyway, it seems like requiring multiple entities to assert my identity before granting access to a protected resource is a "pretty good" safe-guard, and your idea to introduce private keys into the mix is a great enhancement.
Another solution that may present itself in the future (as technology allows it) is the notion of a user becoming his/her own OP. For example, I would love to run my OP on my smart-phone. It's only on when I turn it on, and it tells me if somebody is trying to login as me. If there's an additional layer of security using public/private keys so that RP's can be sure I am who I say I am, all the better. On Fri, Apr 23, 2010 at 3:25 AM, SitG Admin <[email protected] > wrote: > I've been reflecting lately on the OpenID use-case(s) I'd been hoping to > implement, and relevant vulnerabilities in the PKI which v.Next is eager to > write into the spec. > > At 3:30 PM -0700 4/19/10, Allen Tom wrote: > >> Alternatively, if the public key is considered to be public information, >> then it could be shared via Webfinger (again, the RP needs to know who the >> user is already). >> > > Is having the public key considered a sign that the OP can represent the > user? > > It shouldn't be; that's why we call it the *public* key. But unless the > user is involving their private key in an identity transaction^1 somehow, > how does it present any additional assurance that the OP is (still) approved > by that user to represent them, or that the user in question *owns* a > corresponding key? > > Then, even if the user *did* have their private key on hand to provide such > an assurance with, that means their key would be *available* (every moment > they might need to use it for OpenID) to every person and software (from > legitimate but vulnerable to trojan-like) that managed to access it. > (Difficulty applies, sure; and opportunities - but to fend off determined > attackers, something a little more resilient would be nice.) > > Does it matter? I'm assuming that the involvement of a personal key is for > higher levels of assurance in authentication, but perhaps it's just an FYI > feature. Even if it *was* required by a RP, would account recovery/switching > work in favor of the OP vouching for that user, and allow *keys* to be > reset? > > Here's an interesting question - will the user's personal key be used to > *authorize* the OP to represent them? > > A week at a time, for instance; once per week, the user goes through > whatever complicated steps they must to have a secure, offline moment, and > signs for their OP (and possibly *its* (server's) cert) to represent them > for another week. They can even have multiple signed authorization forms > this way, in advance, and keep them offline until needed. If they decide to > change OP's, damage control is already in place. If they can't get to their > private key again for a week, they diminish their reserve but don't > self-DoS. > > This would be a "user-centric" approach. Most users can't support it right > now,and many would have their bank (or similar trusted entity^2) hold it in > escrow for them, localizing trust - but still being no different from > OpenID's outsourcing of trust. Leading me back to the thoughts I had > slightly over a year ago, when first joining this list - that no single > entity ought to be trusted, and their mutual noncooperation can be exploited > to keep power from being centralized in *anyone's* hands - not the user, but > not anyone else, either. Not user-centric, decentralized. > > I don't trust any of the major OP's to not act "on behalf of" their users > *by logging in AS their users* (early caching, active updates of new > content, etcetera; there are many "features" that could be seen as valid > reasons to do this, and Google/Facebook *especially* have been in the news a > lot for allowing the shiny promise of new features to blind them when it > comes to negative consequences), so I can't provide users with the assurance > that "for-their-eyes-only" information will *only* be exposed to them. That, > to me and for them, could be an appalling cost. > > But that leaves me with no trust of OpenID, so I need to find some way of > establishing a minimum level of trust, even if it isn't worth much. (Either > that, or I need to stop using the internet altogether. Such temptations are, > I suspect (and must remember to keep telling myself) nothing more than an > occupational hazard of studying internet "security".) Having reflected on > these matters until I came to a clearer understanding of the difference > between "user-centric" and "decentralized" (as I understand them), I can now > imagine a solution that mixes elements from both approaches: > > Place the public key (rather, the signed authorization for an OP (by cert, > recommended) to speak for the user with that public key) with multiple OP's > - I suggest *not* using Webfinger for this, so as to prevent correlation > (unless the signed authorization doesn't mention any non-key data; then, > correlators could identify alternate services used, at most, but not find > out account names). > > -Shade > > ^1) The process of logging in and exchanging data (or otherwise doing > something) which they are privileged to do on account of their identity. I > clarify this because I'm not confident of my terminology here and I don't > want the words rousing confusion later on as the vocabulary becomes more > precise. > > ^2) Actually, considering the current economic climate, maybe banks weren't > the best choice of example here :) > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
