The spec says (LTI 2p1, sec 4.1):
A comma-separated list of URI values for roles. If this list is non-empty, it should contain at least one role
from the LIS System Role, LIS Institution Role, or LIS Context Role vocabularies (See Appendix A).
The assumed namespace of these URIs is the LIS vocabulary of LIS Context Roles so Tool Consumers can use the
handles when the intent is to refer to an LIS context role. If the Tool Consumer wants to include a role
from another namespace, a fully-qualified URI should be used. Usage of roles from non-LIS vocabularies is
discouraged as it may limit interoperability.
So, technically, our tool consumer SHOULD contain at least one role from the LIS vocabulary, according to the rules about which you can use URIs for and which you can use handles for. If we use a vendor-specific role, I SHOULD use a fully-qualified URI, and use of those is "discouraged".
But we fail the LTI consumer Cert test because the plain string "Student" is somehow considered MUST NOT SEND, not merely 'discouraged'. This appears to fail even if we ALSO send a fully qualified role from the LIS Context
It seems like the spec language should be changed or the cert test should be relaxed, or some other harmonization between the two is needed.
To be clear, our platform launches to LTI 1.1 and LTI Outcomes providers just fine in the real world, and we are keen not to have to write Volkswagen-Diesel emissions test type code switches just to pass conformance.