Decentralized vs. user-centric (was 'Re: 2nd Draft')

SitG Admin sysadmin at shadowsinthegarden.com
Fri Apr 23 03:25:43 UTC 2010


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 :)


More information about the specs mailing list