I thought about throwing something like this online, as I have my own openID provider that could sort of do this. Napkin thoughts:
Privacy isn't actually an easy one on this one. This provider would need to provide a way to "remember" you well enough to allow you to recover parts of your account (any of the credentials, basically). To do this, you do need to store a modicum of data about the user. Ideally:
- Email address or other form of contact
- Challenge-response (to prove you didn't just magically gain access to the email address)
This alone provides huge problems if your goal is privacy, at least when managing the relationship between users of your service and you. You will need to store some of that data, and you need to guarantee that it is safe.
On the link between you and the third-party applications, things get both easier and more complicated at the same time. The OpenID spec specifies that an id_token needs to contain the following, based on scope:
- email: email, email_verified
- profile: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at
In order to provide the privacy you're describing, there needs to be a way for a user, when going through the authentication flow, to allow, deny or spoof the data. Most websites requesting openID will not let you through the gates if you deny one of their scopes, for instance, so the service needs to be able to handle the spoofing part.
The data also needs to be impossible to cross-reference if a parameter is spoofed. Quick thoughts on that:
- The email spoofing must be unique per application ID
- The field spoofing must be unpredictable enough
- All fields of the id_token that can uniquely identify the user must be unique per app, to prevent cross-referencing. The token<->profile lookup must be able to understand this
On the whole, with careful thought about the scope of this, it might actually be pretty straightforward.