1.1 Security

Tools should be cautious to not use this mechanism to store sensitive information that may be valuable outside of the delivery of the tool's activity as values may be exposed to malicious actors for example through Cross-Site scripting vulnerability on either the host learning platform or the tool itself.

2.1 Field Definitions

2.2 put_data

{
  "subject": "lti.put_data",
  "message_id": "...",
  "key": "...",
  "value": "..."
}

{
  "subject": "lti.put_data.response",
  "message_id": "...",
  "key": "...",
  "value": "..."
}

{
  "subject": "lti.put_data.response",
  "message_id": "...",
  "error": {
    "code": "bad_request",
    "message": "The put_data request is missing the 'key' field."
  }
}

2.3 get_data

{
  "subject": "lti.get_data",
  "message_id": "...",
  "key": "..."
}

{
  "subject": "lti.get_data.response",
  "message_id": "...",
  "key": "...",
  "value": "..."
}

{
  "subject": "lti.get_data.response",
  "message_id": "...",
  "error": {
        "code": "key_not_found",
        "message": "..."
    }
}

2.4 Example Usage

The tool pushes a variable into the platforms storage

{
  "subject": "lti.put_data",
  "message_id": "1",
  "key": "keyName",
  "value": "keyValue"
}

The platform pushes a response message back to the tool, this is an acknowledgement that the platform both supports and understands the storage request.

{
  "subject": "lti.put_data.response",
  "message_id": "1",
  "key": "keyName",
  "value": "keyValue"
}

The tool pushes a recall request to the platform

{
  "subject": "lti.get_data",
  "message_id": "2",
  "key": "keyName"
}

The platform pushes the response for the recall request back into the tool.

{
  "subject": "lti.get_data.response",
  "message_id": "2",
  "key": "keyName",
  "value": "keyValue"
}

The tool pushes a clear request to the platform

{
  "subject": "lti.put_data",
  "message_id": "3",
  "key": "keyName"
}

The platform acknowledges the request

{
  "subject": "lti.put_data.response",
  "message_id": "3",
  "key": "keyName"
}

3.1 Web message origin

The web message MUST specify a targetOrigin.

Details on securing postMessage can be found in the LTI Client Side postMessages Specification [LTI-CS-POSTMSG-10]

3.2 Storage Limits

Practical platform implementations have limits on the number and size of entries that they can store. Platforms MUST provide each of the following minimum capabilities:

• At least 4096 bytes per tool (as measured by the sum of the length of the item's key and value).
• At least 500 keys per tool.

Tools SHOULD use as few and as small key-value pairs as possible to avoid reaching these implementation limits.

{
  "subject": "lti.put_data.response",
  "message_id": "...",
  "error": {
        "code": "storage_exhaustion",
        "message": "..."
    }
}

4.1 Time to Live

It is the expectation of this document that the lifespan of the key-value data only lives as long as the platform dictates. At a minimum the data should exist for the as long as the tool frame/window exists. The platform may choose to extend the life of the data to cover multiple launches.

4.2 Storage Encryption

Depending on the implementation the platform chooses to use, if the platform uses a mechanism like local storage, the platform is encouraged to store the values encrypted at rest within the local storage to protect against XSS attacks against the platform. The encryption can be invisible to the tool and the values should only be decrypted only in flight for delivery to the tools endpoint.