We are having courses using the tincan api to report progress in courses to our own learning record store (LRS). The courses are provided by a third party and run in the users browser as HTML pages.
Since all tincan statements send from the course can be manipulated (simple REST interface) we identified that it would be possible to craft or replay a "course success" message which the LRS will accept.
What possibilitys are there to prevent fraudulent messages?
What are common layers of protection?
Great question! Any application that uses client side code (including any SCORM package) is going to be vulnerable to fraudulent data, so this is an important issue to consider.
There's broadly three approaches you can take here depending on your exact situation and how important security is to you.
In a lot of cases online learning is either self-directed so the learner has no incentive to cheat, or is not sufficiently important that it's worthwhile taking the risk of impact on your career by cheating. Cheating may be detected and action taken by a human if the pattern of statements looks odd, or if the learner's subsequent behaviour does not match that of somebody who successfully completed the course.
There may also be easier ways to cheat than sending fraudulent statements, such as asking a colleague or friend for the answers, or finding the correct answer in the code. Security is only as good as the weakest point and if that point is not Tin Can, there's no point focusing your efforts there: don't buy a bigger lock for your door if there's a hole in your wall.
To support this approach, Tin Can statements have an authority property that states who asserted the thing happened. This allows reporting tools and users viewing the data to determine how much they trust that data.
For any client side tracking, that level of trust should be relatively low, but in many cases, that's ok. Bear in mind that the two main ways of finding out about people in order to offer them jobs are CVs and interviews, both of which rely on the employee's self assertion. The important thing is to know how reliable the data is.
If you have to use client side tracking, you can improve security a little by restricting the permissions and scope of credentials used to launch the content. Consider what data you expect the course to send, and limit the credentials to that data set. This approach won't stop an individual learner claiming to have passed the course, but will prevent them from issuing statements about other learners or other courses. It's damage limitation, not prevention, but brings the security of your client side tracking up to the same level or slightly higher than you had with SCORM.
If security really is important to you, then only choice (which wasn't available in SCORM) is to do the tracking server side. There's free open source code libraries for many of the main server side languages. Tracking server side allows you to hide the credentials from the learners computer, so the risk of anybody getting at these credentials and sending fraudulent statements is much lower.
As I mentioned above, you do need to make sure you've addressed the rest of the chain too. Server side tracking may be a pointless investment if questions are marked client side (the learner can find the correct answers in the code), or if there's no way of verifying the identity of the user being assessed (their friend can sit the test for them).
If you've already got your courses using client side tracking, perhaps created by an authoring tool, this option is likely to be the most expensive, so you'll need to consider how important security is. Some adopters have taken the approach of using client side tracking for the learning experience, followed by a server side tracked assessment.
All in all, Tin Can has the potential to be considerably more secure than SCORM if done right, but you do need to think through the whole process end to end, and not just the tracking.
Let me know if you have any follow up questions on any of these three approaches.