3 karma · joined October 3, 2017
Suppose your CEO and the entire board is hustling on daily ops as you supposed in the intro. What makes you think any employee in there will be able to bring in a third-party, outsider company to suddenly bring order, clear the backlog, clear production and deployment issues and clear up the flow without the CEO going "We're not having any of this"?
Not sure what I find funnier - that Brexit was delayed to october 31st, making this invalid, or that it takes 306kb to display a counter ;-)
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.