Loomio

OpenID Connect : which claims to communicate ?

DU Public Seen by 26

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?

JR

Jason Robinson Thu 9 Jul 2015 4:22PM

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

JR

Jason Robinson Thu 9 Jul 2015 4:23PM

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.

KS

Kent Shikama Thu 9 Jul 2015 4:25PM

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

JR

Jason Robinson Thu 9 Jul 2015 4:26PM

@theworldbright good idea, +1

G

goob Thu 9 Jul 2015 5:47PM

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!

DU

Thu 9 Jul 2015 7:33PM

I think email should definitely stay private!

I think too.

G

goob Thu 9 Jul 2015 7:58PM

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

Jason Robinson Thu 9 Jul 2015 8:00PM

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.

DU

Fri 10 Jul 2015 1:43PM

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?

JR

Jason Robinson Fri 10 Jul 2015 5:31PM

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.

Load More