OpenID Connect : which claims to communicate?


(Augier) #1

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.


(Jason Robinson) #2

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 :slight_smile:


(Jason Robinson) #3

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.


(Kent Shikama) #4

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


(Jason Robinson) #5

@theworldbright good idea, +1


(goob) #6

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.

I think email should definitely stay private!


(Augier) #7

I think email should definitely stay private!

I think too.


(goob) #8

I was responding to:

IMHO, at least the following must stay secret:

  • name (full name and surname),
  • given_name (basically, first name),
  • family_name (surname),
  • gender,
  • birthdate,
  • updated_at (time of profile’s last 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).

(Jason Robinson) #9

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.


(Augier) #10

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?


(Jason Robinson) #11

But I think I remeber there was some times ago a proposition to drop the email from the subscription fields?

What do you mean by subscription fields? I don’t at least remember any proposal to drop email from anywhere.


(Augier) #12

I think I remember someone proposed to let the email be an optional field to subscribe. I don’t rememer where.


(Kent Shikama) #13

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).