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

David Fuelling sappenin at gmail.com
Mon Apr 26 14:52:58 UTC 2010


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 <sysadmin at shadowsinthegarden.com
> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100426/ca82551e/attachment.htm>


More information about the specs mailing list