PII Sharing in LTI 1.3 Works Inconsistently

[michaelroytman]

PII sharing in LTI 1.3 launches works inconsistently and potentially has a few bugs.

How Do We Enable PII Sharing?

As a review, there are two key pieces of data that control when PII is shared in LTI. This summary comes from reading the code and from the Unified Flag for Enabling Sharing of PII in LTI ADR. It summarizes how these data are used in LTI 1.1.

• CourseAllowPIISharingInLTIFlag: a configuration model that controls whether two LtiConsumerXBlock fields ask _to_send_username and ask_to_send_email are editable in Studio and whether their values are respected for PII sharing. If this model not enabled, PII should not be shared, regardless of the value of the aforementioned fields.
• ask_to_send_username, ask_to_send_email: two LtiConsumerXblock fields that are editable in Studio if CourseAllowPIISharingInLTIFlag is enabled; they control whether to send the username and email claims in the LTI ID token, respectively.

How Does PII Sharing Work in LTI 1.3?

LTI 1.3 Resource Link Launch

• Neither the username nor email claim is sent in the LTI ID token, regardless of the values of the pieces of data above.
• If either or both of ask_to_send_username or ask_to_send_email are enabled, a PII sharing consent modal appears before the LTI launch. Even though this consent modal is displayed, no such data is ever shared.
• The CourseAllowPIISharingInLTIFlag is not used to determine whether to display this modal - only ask_to_send_username and ask_to_send_email.
• The PII sharing consent modal appear before an LTI 1.3 launch only for modal or new_window launches, not inline launches.

LTI 1.3 Names and Role Provisioning Context Membership Service Call

• CourseAllowPIISharingInLTIFlag is used to determine whether to send PII, but ask_to_send_username and ask_to_send_email are not used; PII is shared if CourseAllowPIISharingInLTIFlag is enabled
• The data that are sent are name and email, not username and email. The ask_to_send_username and ask_to_send_email fields would suggest that we should send username and email (even though these fields are not used).

Recommendations

• CourseAllowPIISharingInLTIFlag should also control whether the PII sharing consent modal is displayed.
• The PII sharing consent modal should appear before inline LTI launches as well.
• When CourseAllowPIISharingInLTIFlag is enabled, the LTI launch should include PII, depending on the values of ask_to_send_username and ask_to_send_email.
• The LTI 1.3 Names and Role Provisioning Context Membership Service endpoint should send username and email if and only if CourseAllowPIISharingInLTIFlag is enabled and ask_to_send_username or ask_to_send_email are enabled, respectively.
• The LTI 1.3 Names and Role Provisioning Context Membership Service endpoint should send a username claim instead of a name claim when ask_to_send_username is enabled.

Questions

• What is the history and set of decisions underlying this PII sharing behavior? Was it intentionally implemented this way?
• Can PII be shared in LTI 1.3 launches? Is there any history of legal concerns?
• Is there a reason that the PII sharing consent modal does not appear for inline launches? Is this intentional or unintentional? Is it a limitation of the frontend technology?
• We would like to extend PII sharing to include other user identity claims that tools can reasonably expect - see list here, like name. Is this of any concern?

[giovannicimolin]

@michaelroytman +1 to all recommendations.

What is the history and set of decisions underlying this PII sharing behavior? Was it intentionally implemented this way?

I think the PII implementation was never given much though, so different settings were implemented on a per need basis. Maybe we should re-look at how it works and make it consistent (both across LTI versions and use cases).

There's also de LTI-NRPS which sends over usernames and passwords when CourseAllowPIISharingInLTIFlag is enabled if I'm not mistaken.

Can PII be shared in LTI 1.3 launches? Is there any history of legal concerns?

It can, but the potential risk is that anyone creating a course can set up an LTI tool. A malicious user could use a tool to extract user information from the platform. I'm not sure if the legal discussion ever moved forward after this, and this is why the default is super restrictive.

Is there a reason that the PII sharing consent modal does not appear for inline launches? Is this intentional or unintentional? Is it a limitation of the frontend technology?

I think the modal not showing up on inline launches is a bug. There were some changes to this behavior in the past: #204.

We would like to extend PII sharing to include other user identity claims that tools can reasonably expect - see list here, like name. Is this of any concern?

I think the concern here is more legal than anything else (sending PII to external tools is tricky).
We can work with either a course whitelist (using the current flag to enable/disable PII) or with a tool whitelist (but it might be too much of an effort to implement, and hard to maintain).

[usmanpm]

Grooming Update 11/14/25: This ticket is useful, however we need to investigate if the LTI NRPS is a replacement for this. We will continue to investigate.

[ayub02]

I've tried to review the issues reported in ticket's description in context of Ulmo release.

LTI 1.3 Resource Link Launch:

Neither the username nor email claim is sent in the LTI ID token, regardless of the values of the pieces of data above.

This is no longer true. Username, email and full name is sent in the LtiResourceLinkRequest if user provides consent in the modal shown before the launch.

If either or both of ask_to_send_username or ask_to_send_email are enabled, a PII sharing consent modal appears before the LTI launch. Even though this consent modal is displayed, no such data is ever shared.

This is no longer true, as reported above.

The CourseAllowPIISharingInLTIFlag is not used to determine whether to display this modal - only ask_to_send_username and ask_to_send_email.

This is true. CourseAllowPIISharingInLTIFlag only seems to control visibility of Request user's username/email/fullname fields in the LTI Consumer XBlock configuration modal.

The PII sharing consent modal appear before an LTI 1.3 launch only for modal or new_window launches, not inline launches.

This is no longer true. Modal appears for all 3 appearance options.

LTI 1.3 Names and Role Provisioning Context Membership Service Call:

CourseAllowPIISharingInLTIFlag is used to determine whether to send PII, but ask_to_send_username and ask_to_send_email are not used; PII is shared if CourseAllowPIISharingInLTIFlag is enabled

This is true. CourseAllowPIISharingInLTIFlag determines whether or not the platform share username and email in response to memberships call by the tool, irrespective of the state of ask_to_send_username and ask_to_send_email configs.

The data that are sent are name and email, NOT username and email. The ask_to_send_username and ask_to_send_email fields would suggest that we should send username and email (even though these fields are not used).

This is true.

Recommendations

The LTI 1.3 Names and Role Provisioning Context Membership Service endpoint should send a username claim instead of a name claim when ask_to_send_username is enabled.

Username is NOT part of sample json given in the spec: https://www.imsglobal.org/spec/lti-nrps/v2p0#:~:text=%C2%A0%C2%A02.1%20Membership%20container%20media%20type