Shade,<div><br></div><div>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 ((<a href="https://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html">https://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html</a> -- 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. </div>
<div><br></div><div>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.</div>
<div><br></div><div><div class="gmail_quote">On Fri, Apr 23, 2010 at 3:25 AM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
At 3:30 PM -0700 4/19/10, Allen Tom wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br>
Is having the public key considered a sign that the OP can represent the user?<br>
<br>
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?<br>
<br>
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.)<br>
<br>
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?<br>
<br>
Here's an interesting question - will the user's personal key be used to *authorize* the OP to represent them?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
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).<br>
<br>
-Shade<br>
<br>
^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.<br>
<br>
^2) Actually, considering the current economic climate, maybe banks weren't the best choice of example here :)<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote></div><br></div>