[OpenID] Using OpenID to store encrypted data

[SitG Admin]

>Is there any standard way of achieving this using OpenID?

The short answer - no. OpenID was designed to be compatible with the 
existing web, requiring no additional software (or a special browser) 
to function. OpenID covers itself only - not all the uses that we may 
find for it.

The long answer - would you like to create a standard way of achieving this? :)

If you open-source whatever you do, others can help out - and some of 
us probably will, since it sounds like a good application for 
promoting OpenID's usefulness on the web.

>I have a web application which uses OpenID to identify my users. For 
>each user I'd like to store some encrypted data that only the user 
>should be able to retrieve. For that I need a key which is _not_ 
>stored in my application.

I have considered this problem previously. The trick is that, if 
*you* need the key at all, you're decrypting the data on your end 
before sending it to the user - and then all an attacker has to do is 
break into your machine, install some spyware, and wait for the user 
to log in (or, imitate the user). If you know what encryption key to 
use for a given user, you also know what their OpenID (the obvious 
"secret" string) will be, and in watching for this you also have the 
string to watch for contained in your code! You might be able to add 
some obscurity to this by looking for a hash rather than the exact 
string itself, but also consider how easy it could be for attackers 
to discover the OpenID's of people you associate with (that might be 
using your site) or to search for your site using Google to discover 
who has mentioned it (and therefore might be a user of it). Also, 
access logs *may* reveal OpenID request strings (since they pass some 
OpenID arguments as part of the URL), which would reveal URI's to 
anyone breaking in.

Then you have passwords (from the user) and private key systems. If 
you can count on your users having Firefox, there is an add-on that 
will handle decryption on their end, and you can merely use OpenID to 
restrict who gains access to that information (reducing bandwidth by 
eliminating frivolous requests).

>I think that ultimately what I'd like is that the OpenID provider 
>returns a response consisting of the claimed_id (used as a user 
>identifier in my application) together with a piece of data (acting 
>as a key)

So the OP, which normally has the power to pose as your user, will 
now be able to dictate their key as well? Sounds to me like you may 
as well go with HTTPS for transmission of the sensitive data and 
forget about a second layer of encryption, since the OP will be able 
to compromise the user's privacy effortlessly if you do it that way.

-Shade