Sharebar?

LTI 1.3 interoperability issues

LTI 1.3 interoperability issues

I have been testing different LTI platforms (including ones listed as being certified by IMS) for their support of LTI 1.3 and encountered a few interoperability issues which I wanted to bring to the attention of others in case they are not intended, or so they can correct my misunderstandings.

  1. My reading of the OpenID Connect spec is that Authorization Servers must support Authentication requests sent using both HTTP GET and POST methods. However, at least one IMS certified LTI platform only supports one of these methods. Is the IMS Security Framework intending to relax this requirement, or is it just something which is not included in the certification testing? From the perspective of a tool, it would be very helpful for platforms to support both methods so that a tool need not be concerned about which one it has to use for specific connections.
  2. The state parameter in Authentication requests is given as only being recommended in the IMS Security Framework, but I have found more than one certified platform which requires this parameter to be both present and non-empty. Which is correct?
  3. For JWTs used for message security, the IMS Security Framework says that the aud claim may be a string value if the array only has one value. This special case is not mentioned for JWTs used for securing web services. However, I have come across one certified platform which only accepts a string value for the aud claim with web services, and generates a 500 Server Error when an array is used. Is the intention to allow the special case to apply to all IMS JWTs? Is it really permissible for a system to only accept one format and not both for the aud value? It would, of course, be a lot simpler to remove such areas of choice, but given that they are permitted some additional clarity would be helpful here.
  4. I may have missed this information, but I think it would be very helpful to have a simple list of the values which need to be shared out-of-band between platforms and tools. In many cases I found it difficult to discover the values to be shared by platforms, especially the identity value for access token requests (used as the aud claim). In most cases I found that platforms expect this to be the same as the endpoint to which the request is to be sent, but none appeared to be explicit about this. Indeed it could be useful to define a JSON (or other) format for the data to be shared so that systems could provide simpler interfaces to configure the LTI connections.
  5. My reading of the IMS Security Framework is that the response to an access token request must contain a scope element which confirms which scopes the token can be used for. However, I have found one certified platform which does not include the scope element in its response. Is this an error in the spec or should this platform not have been certified?

Thanks.

Hi Stephen!

Hi Stephen!

1) I'm not sure about what's required or intended off-hand. I believe the consensus is that tools and platforms should both support both POST and GET. We'll have to look into if the docs should be improved to make this all clear.

2) It's recommended that platforms use it, but they don't have to. If a tool receives a state param it MUST return it, and the platform would require that it's returned.
So I guess you could say it's optional for platforms but required for tools.

3) I agree, additional clarity is needed, and perhaps another certification test around it.


4) Agreed, there is a lot to improve with registration. We think the dynamic registration spec that's moving forward will help with most of these problems. That spec is waiting for a couple implementors, but all the LMS' are planning to implement it.

5) I'm not sure. It may be that you weren't allowed any of those scopes so they weren't returned? I can pass some info on to Dereck to check on if you email me or him.

Re: LTI 1.3 interoperability issues

Thanks for the reply Bracken.

  1. Since submitting my original post, I found that section 3.1.2.1 of the OpenID Connect Core 1.0 spec states that "Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 2616 at the Authorization Endpoint". I have found nothing in the LTI specs which remove this requirement. At least making sure that certified platforms support both would be very helpful.
  2. In that case can you ensure that certified platforms do not require this parameter as is currently the case for some?
  3. Thanks, definitely need a certification test because at present there is at least one certified platform which does not accept a message with an array for this claim as per the example in the spec.
  4. Thanks, that sounds useful but, in the meantime, just a simple list of data which need to be shared from each end would be helpful.
  5. This was not the case; a token was returned but without any scope element. And the token was usable. Section 4.1 of the Security Framework states that "the response MUST include a scope parameter", yet not all certified platforms do so. What is a tool expected to assume when no scope is returned - that all requested scopes have been accepted?

Interoperability issues

Hi Stephen,

I recently fixed Blackboard Learn to support POST on an OIDC auth request.

I also recently fixed Blackboard Learn to not require state, though it troubles me that you wouldn't send a state parameter

I also recently fixed Blackboard Learn to support an array for the aud claim

Can you tell us which platform isn't returning a scope value? It would be helpful to know if it's Blackboard Learn so I can fix it.

"My reading of the IMS Security Framework is that the response to an access token request must contain a scope element which confirms which scopes the token can be used for. However, I have found one certified platform which does not include the scope element in its response. Is this an error in the spec or should this platform not have been certified?"

 

Re: Interoperability issues

Thanks Eric, that is great news and great timing as I'm about to release an update to my LTI class library for PHP and I will now be able remove the hard-coding check for a Blackboard platform in the LTI 1.3 code.

I don't belive I ever said that I did not want to send a state parameter, but in my testing I found several platforms which required it even though it only appeared to be recommended in the relevant specification; hence my question.

I do not wish to publicly name and shame any of the certified platforms which I found as being non-compliant, but the scope issue was not with Blackboard.

Re: LTI 1.3 interoperability issues

From the responses posted, it seems there is agreement that items 1, 2, 3 and 5 that I raised last April should not be present in LTI systems. Please can someone confirm that tests have now been added to the IMS certification system to remove these interoperability issues from certified systems.

More recently, my tests of certified platforms have found one which does not appear to check that the access token being sent to a service endpoint was issued for the scope relevant to the request being made. For example, when an access token issued with a single scope of "https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly" is passed to the Line-Item service endpoint, the service request is still successful. I am not suggesting that, in the case found, the request would have been successful had the service not been made available to the tool (such that it could have successfully asked for a token with the relevant scope), but I assume that platforms should be requiring appropriately scoped tokens.

I have also found a certified platform which does not accept the full name of a role (e.g. "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner") as the value of the role query parameter in a request to the Names and Role Provisioning Service. It only accepts the short form (e.g. "Learner") which, on my reading of the spec should be an option but not the only required format.

I don't think the Names and Role Provisioning Services spec is explicit about this, but should platforms return all members of a context, or are they allowed to only return Learners and not, for example, Instructors? I found one certified platform which is only returning users with a role of learner in response to requests to this service.

So perhaps some further tests are needed in the certification system to cover such cases.

Thanks.