Allow OpenID users to select which information to send to the Relying Party

[James Henstridge]

We currently have limited support for OpenID Simple Registration Extension where we will unconditionally send certain information (nickname, fullname, email) to certain known relying parties.

After phase 1 is complete it'd be good to improve this:
 * limit the data sent to that which the RP says is required (through the openid.sreg.required parameter) or optional (openid.sreg.optional)
 * should we give the user the option to decide which pieces of data to provide (as opposed to providing everything requested or not authenticating at all)?
 * decide whether some of the info we know about the user is okay to disclose to third parties with the user's permission. For this info, we should provide without checking the openid_limited_sreg config value.

[James Henstridge (jamesh)]

I ended up improving the sreg code. It now limits what data it sends to that which is requested by the user.

I also removed the openid_limited_sreg configuration key in favour of per-site limits on what information may be disclosed.

So that just leaves allowing the user to pick what info to disclose (not sure whether we want this), and having a default policy for what info to disclose to unknown sites.

[Greg Grossmeier (greg.grossmeier)]

"So that just leaves allowing the user to pick what info to disclose (not sure whether we want this)"

As some sites do not provide full privileges to users unless they supply an email (like wikis) then having the ability to tell LP what information I want sent to a specific site would be helpful. I could send all my information to a site I trusted (name, email, bday, location, jabberID, etc etc) but only username to a site I was simply testing out.

Short version:
+1 to allowing the selective sending of additional information to OpenID-enabled sites.

[James Westby (james-w)]

Hi,

What's the current status of this? Using a site that uses sreg, but isn't on a launchpad
whitelist I can only get nickname to be provided by lp, regardless of whether e.g. fullname
is said to be required. The original bug says:

> We currently have limited support for OpenID Simple Registration Extension where we will
> unconditionally send certain information (nickname, fullname, email) to certain known relying parties.

so that explains that.

My observations of the current behaviour suggest that the nickname is unrestricted, but
the fullname and email will not be sent to unknown sites. It would be great to at least
give the user the option of allowing them to be sent, otherwise you can get reduced
or no functionality on other sites.

Thanks,

James

[Martin Zuther (mzuther)]

Hi!

I'm not good in OpenID terms and also don't know if this is the appropriate place...

But I think for a good OpenID user experience, you need a page:

* showing which websites were permanently allowed
* allowing to revoke websites that were permanently allowed
* showing which data were transferred (username, email address etc.)

Finally, it would be nice to edit and store the information (especially the transferred username) before submission to the referring website. Imagine you have the launchpad nickname "everybody" and want to log into a website were the user "everybody" already exists and is owned by someone else. As far as I see, there is no way of logging in via launchpad OpenID, except permanently changing the launchpad nickname.

Thanks for listening,

Martin

[Stuart Metcalfe (stuartmetcalfe)]

Tentatively assigning to the 2.7.0 release. It'd be great to add some of this functionality so we'll give it some thought and see what we can commit to.

[Stuart Metcalfe (stuartmetcalfe)]

Here's an opening suggestion for different behaviours:

Trusted sites:

 * SReg required: Will always be sent if available. No option to uncheck. Text bold
 * SReg optional: Provide checkbox (checked by default). Text plain

Untrusted sites:

 * SReg required: Provide checkbox (checked by default). Text bold
 * SReg optional: Provide checkbox (unchecked by default). Text plain

For teams, we should consider using a js expander so that the default is a collapsed section where all teams are controlled by a single checkbox (eg: "> [x] Teams: team_x, team_y"). Individual teams can be checked/unchecked by expanding the section.

Specific behaviours:

Trusted sites: Provide checkboxes (checked by default). Text plain
Untrusted sites: Provide checkboxes (unchecked by default). Text plain.

We should save all field states per trust root for each user and restore their checked state on each login. If teams are individually selected then the section should be expanded and individual checkbox states restored on subsequent logins. Fields no longer requested by the consumer should be removed from the saved list so they revert to the default state if they are added again later. New fields on subsequent logins should follow the defaults above but also have italic text or be highlighted in a similar way. New teams should follow the defaults above, the section should be expanded, and new teams in the list should be highlighted as for new fields.

[James Westby (james-w)]

On Wed, 30 Jun 2010 10:08:54 -0000, Stuart Metcalfe <email address hidden> wrote:
> Here's an opening suggestion for different behaviours:
>
> Trusted sites:
>
> * SReg required: Will always be sent if available. No option to uncheck. Text bold

This would still show the information that would be sent?

Thanks,

James

[Stuart Metcalfe (stuartmetcalfe)]

> This would still show the information that would be sent?

Yes, definitely.

[Anthony Lenton (elachuni)]

Moved to 2.9.0 to make space in 2.8 for Ubuntu 10.10 critical tasks

[Stuart Metcalfe (stuartmetcalfe)]

Moved to 2.10 as it's not release critical for Ubuntu 10.10 and we're seeing some build-up of more important tasks.

[Stuart Metcalfe (stuartmetcalfe)]

It's worth noting, for QA, that if a requesting site (trusted or untrusted) adds *additional* information in subsequent requests, any auto-login settings should be ignored so that the user can review the extra info before approving the request.

[Danny Tamez (zematynnad)]

FOR QA:

The branch adds enhancements to the decide page. It provides checkboxes that let the user decide whether or not to send individual items requested by the consumer on to the consumer. It remembers the state of those choices for the next time the user is presented with those options. It also employs javascript to condense multiple teams that are requested with a single line and one checkbox for convenience. The user can choose to expand the list and deselect or select individual teams as desired. One part of the bug is not implemented because of another SSO bug and that is the section dealing with additional info requested from the consumer changing the behavior of auto login.

To test:
fab bootstrap
fab setup_postgresql_server
. .env/bin/activate
./django_project/manage.py loaddata tests.json
fab run

Go to http://localhost:8000/consumer
select whatever sreg data you wish to request.
for the teams you can enter the following: ubuntu-team,kubuntu-team,isd-team

[Dave Morley (davmor2)]

There is an issue trying to test this fully in that the only reliable consumer is LP and they don't seem to have the attributes to require anything, and then the test consumer which isn't a trusted consumer so required remain editable.

What we need to do is keep a close eye on this going forward and maybe modify to auto-auth where necessary to prevent end user unchecked require fields as a temporary fix.