This represent a questionning that concerns me since a few days. The implementation of OpenID Connect is currently going on and I’m starting to ask myself which data on the user diaspora should communicate and which it shouldn’t during a connection procedure with OIDC.
OIDC specifies a lot of claims. Whil most of them are not even know by diaspora, some of them could be given by it during a connection procedure like the profile picture or the email address.
Then, the question is: which of them can be given and which must stay private?
The following claims are potentially know by diaspora:
name (full name and surname),
given_name (basically, first name),
family_name (surname),
nickname,
profile (basically, should be diaspora’s profile page of the user),
picture (user’s avatar),
email,
gender,
birthdate,
zoneinfo (time zone),
updated_at (time of profile’s lat update).
IMHO, at least the followinf must stay secret:
name (full name and surname),
given_name (basically, first name),
family_name (surname),
gender,
birthdate,
updated_at (time of profile’s lat update).
This leaves the following informations to be potentially public during an OIDC connection procedure:
nickname,
profile (basically, should be diaspora’s profile page of the user),
picture (user’s avatar),
email,
zoneinfo (time zone).
A solution could be to add a configuration page which lets the user choose what can be communicated about him.
IMHO, at least the username should stay public with the sub (the user’s unique ID, i.e, the diaspora handle).
What do you all think about this?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Just keep it really simple and basic without any additional settings pages in the initial implementation so we get the API in as soon as possible, is my vote
Also, handle and profile picture are public information anyway, so those at least can be given out to a client too. Anything else depends on the client features whether it needs that info.
Hmm maybe we can just split it into two scopes: basic and extended. Basically, basic will be just what you mentioned can “be potentially public” and extended would be everything else included. It will then match nicely with what we currently have in terms of profile visibility options. We can adjust the name of those two scopes based on the result of the discussion here: https://github.com/diaspora/diaspora/pull/6162/files#r34268281
I agree with @theworldbright - to start with, just include what is already public in the ‘basic’ profile: diaspora ID, nickname and avatar, and profile page (which isn’t part of the profile information, but is also publicly available). In the future, perhaps other profile fields which a user has set to be public could also be included, but to start with, let’s include just the basic information which is always public.
I hope that information will be enough to verify an ID.
There is sure to be a use case where the client needs to retrieve the user email via the API. This does not make it public - it makes it available to the client after user has authorized that.
There is sure to be a use case where the client needs to retrieve the user email via the API.There is sure to be a use case where the client needs to retrieve the user email via the API.
But I think I remeber there was some times ago a proposition to drop the email from the subscription fields?
I’m personally fine with allowing the email field to be passed through. However, until we seem to get a consensus here I’m going with the following for the “basic” profile: %w(sub nickname profile picture zoneinfo).
