1EdTech Proctoring Services Specification

1EdTech Proctoring Services Specification

1EdTech Candidate Final Public
Version 1.0
IMS Candidate Final Public
Document Version: 2
Date Issued: July 2019
Status: This document is for review and adoption by the IMS membership.
This version: https://www.imsglobal.org/spec/proctoring/v1p0/
Latest version: https://www.imsglobal.org/spec/proctoring/latest/
Errata: https://www.imsglobal.org/spec/proctoring/v1p0/errata/

IPR and Distribution Notice

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

The following participating organizations have made explicit license commitments to this specification:

Org name Date election made Necessary claims Type
Questionmark July 30, 2019 No RF RAND (Required & Optional Elements)

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources.

© 2021 1EdTech Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

Abstract

The 1EdTech Proctoring Services specification is based on the Learning Tools Interoperability (LTI)® Core v1.3 specification and LTI™ Advantage services [LTI-13]. LTI works on the concept of a browser-based launch from a platform into an external tool or application. For proctoring, a test delivery or assessment management system would be the platform and the proctoring service the tool.

1. Introduction

Overview

1EdTech is developing the Proctoring Specification to allow platforms used for assessment to integrate more easily with tools used for proctoring candidates taking assessments on those platforms.  Using the Proctoring Specification a candidate can launch out from their assessment platform to the proctoring tool, initiate a proctored session with that tool, and be returned securely back to the assessment platform to take the assessment while being proctored by the proctoring tool.

The Proctoring Specification also provides a method for proctoring tools to send messages to the assessment platform during the assessment to control a candidate's progression including, if necessary, a facility to terminate the assessment.

Figure 1 Basic flow of actions and actors involved in a proctoring interaction.
An LTI based platform integrates with an assessment platform (via an admin or test candidate) that then launches a session between a Proctoring Tool via the Proctoring spec

This document uses terminology and concepts introduced in the LTI 1.3 specification [LTI-13], specifically:

  • Platforms and Tools as participants in an LTI workflow
  • An LTI Launch
  • Users and Roles
  • Authentication
  • Messages and services

In the context of this specification the Platform is defined as the system that contains the assessment content and is referred to as the Assessment Platform.  This could be an LMS with an integrated quizzing tool or it could be a dedicated Assessment Management System (AMS).

In this specification, the Tool is defined as the system that provides additional proctoring services used in conjunction with the Assessment Platform and is referred to as the Proctoring Tool.

Document Set

Normative Documents

Start Proctoring Message JSON Schema The Start Proctoring Message JSON Schema defines syntactical restrictions on the Start Proctoring Message JSON payload.  URL: https://purl.imsglobal.org/spec/lti-ap/v1p0/schema/json/startproctoringmessagev1p0.json

Start Assessment Message JSON Schema The Start Assessment Message JSON Schema defines syntactical restrictions on the Start Assessment Message JSON payload.  URL: https://purl.imsglobal.org/spec/lti-ap/v1p0/schema/json/startassessmentmessagev1p0.json

End Assessment Message JSON Schema The End Assessment Message JSON Schema defines syntactical restrictions on the End Assessment Message JSON payload.  URL: https://purl.imsglobal.org/spec/lti-ap/v1p0/schema/json/endassessmentmessagev1p0.json

Assessment Control Request Message JSON Schemas The Assessment Control Request Message JSON Schema defines syntactical restrictions on the Assessment Control Request Message JSON payload.  URL: https://purl.imsglobal.org/spec/lti-ap/v1p0/schema/json/assessmentcontrolrequestmessagev1p0.json

Assessment Control Response Message JSON Schemas The Assessment Control Response Message JSON Schema defines syntactical restrictions on the Assessment Control Response Message JSON payload.  URL: https://purl.imsglobal.org/spec/lti-ap/v1p0/schema/json/assessmentcontrolresponsemessagev1p0.json

1.1 Terms and Definitions

1.1.1 Terminology

1.1.1.1 Actors and Domain
Academic Integrity Officer
Officer responsible for Test Integrity who may need to review information generated by both the Assessment Platform and the Proctoring Tool in order to ensure that assessment process is fair. For the purposes of this specification, a specialized Reviewer.
Assessment
The instrument created within the platform system to evaluate candidate.
Also known as a test, exam or examination.
Assessment Administrator
Role within an institution responsible for the running of a specific assessment within an assessment program; may also be known as Test Administrator.
Assessment Platform
The system that the candidate logs in to, for example, a learning management system, and where the candidate launches the assessment.
Candidate
Test taker. The person that is taking an assessment. Often used to differentiate between a generic user of a presentation system (which could be a proctor or administrator), and the actual candidates taking the assessment.
Examinations Officer
See Academic Integrity Officer.
Proctor
Also known as an Invigilator. A person supervising the candidate during the assessment either in person or via remote conferencing technology.
Program Administrator
Role within an institution responsible for the day to day running of (part of) an assessment program.
Program Manager
Role within an institution responsible for the overall running of an assessment program.
Reviewer
Person responsible for reviewing data (evidence) collected by the Proctoring Tool in order to verify that the assessment was conducted fairly.
Test Center Administrator
When Proctoring is being performed in person, at a Test Center the Test Center Administrator is responsible for the operation of the Test Center and the equipment that will be used during the assessment.
1.1.1.2 Technical Terminology
ACS
Assessment Control Service (defined by this specification)
JWT
JSON Web Token is a JSON-based [RFC7159] security token encoding that enables identity and security information to be shared across security domains. A security token is generally issued by an Identity Provider and consumed by a Relying Party that relies on its content to identify the token's subject for security-related purposes.
LTI
Learning Tools Interoperability® (LTI®) is an 1EdTech standard for integration of rich learning applications within educational environments.

2. Proctoring Use Cases

The use cases in the following sections are arranged in priority order.  These priorities have been used to guide the development of the specification.  High priority use cases generally give rise to requirements (the system MUST do something) whereas the lower priority use cases are more likely to be optional (the system SHOULD do something or MAY do something).

The following diagram has been provided to help visualize these use cases in the context of the assessment delivery process.

The following are brief descriptions of the use cases defined and addressed in this specification. For full use case descriptions, see Appendix A.

  • Proctoring-01: Launch the Assessment Launch the assessment through the proctoring service.
  • Proctoring-02: Add Proctoring Requirement Add proctoring requirement to an assessment.

The protocol documented by this specification does not cover the method by which the Proctoring Tool is made active for an assessment within the Assessment Platform.

  • Proctoring-03: Proctor Intervenes Control a running assessment to protect integrity of the process.This use case presupposes that the Proctor is able to interact with the Proctoring Tool through their own device.  This does not exclude local 'in person' proctoring as a local proctor may still have access to a device used to manage the assessment session.  A local proctor may also be able to intervene directly, e.g., by powering off the Candidate's computer to prevent them cheating or stealing assessment content.
  • Proctoring-04: Validate User System Check technology requirements for a specific PC, laptop or other device prior to the scheduled assessment time.Most Proctoring Tools do some form of technical system checking process to ensure that the necessary software and hardware is available during the assessment launch.  In addition to these just-in-time checks some Proctoring Tools provide a way for candidates to 'dry run' their technology well in advance of the scheduled assessment to give them plenty of time to install required software or change system configuration.  This use case refers to these advanced checks only.
  • Proctoring-05: Site-Wide Proctoring Options Configure proctoring options that will apply to all assessments delivered within the institution.
  • Proctoring-06: Assessment Specific Proctoring Options Modify default  proctoring options for an individual assessment.
  • Proctoring-07: External Reviewer Launch of Proctoring System Review audit information for entire assessment program.

2.1 Conformance Statements

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119].

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The Conformance and Certification Guide for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

3. Proctoring Launch Workflow

Figure 3 A diagram showing the flow of actions between different systems during a proctoring session. See the full text description below.
  1. The Assessment Platform redirects the candidate's browser to an endpoint hosted by the Proctoring Tool, as with the core LTI resource link launch request, initiating the proctoring process provided by the tool
  2. The Proctoring Tool provides a user interface allowing the candidate to initiate the proctoring process, including interaction with a live proctor if required by the tool.
  3. Once the candidate's browsing environment has been secured by the Proctoring Tool the tool redirects the user's browser back to the Assessment Platform using a special form that allows them to start the assessment.
  4. During the assessment the Proctoring Tool may use the service defined by this specification to interact directly with the Assessment Platform in order to control the assessment (not shown in this diagram).

The diagram shows all interactions taking place in the same browser (UA) session.  This is critical to the security model underlying the LTI protocol.  Proctoring Tools that require a specific browser must ensure that the candidate starts their session with the Assessment Platform in that browser.  Proctoring Tools MUST NOT attempt to create a new browser session during the proctoring-specific security flow.  

3.1 Transferring from Platform to Tool

When the user initiates the assessment process in the Assessment Platform their browser session (user agent) is transferred to the Proctoring Tool by sending the Start Proctoring message using the message security and signing protocol defined in [SEC-10] (Platform-Originating Messages) which is based on OpenID Connect.

The platform sends the same message parameters in the Start Proctoring message as it would in the resource link launch request message defined in [LTI-13], along with some additional parameters.

The message_type of this new message has a value of LtiStartProctoring.  Given the intended workflow implied by this message type, the platform may open the Proctoring Tool in a new window or replace the current UI context completely.  The Proctoring Tool MUST support both modes.

In the OpenID Connect exchange, the Assessment Platform plays the role of the Identity Provider or OpenID Provider (OP) and the Proctoring Tool plays the role of the Relying Party (RP).  The detailed flow is summarized below:

  • The Assessment Platform triggers a Third-party Initiated Login sending a small GET or auto-submitted POST request to the Proctoring Tool's login endpoint identifying the Assessment Platform (the OP, also known as the issuer and sent in the iss parameter), the user logged in to the platform (the login_hint parameter) and the Tool's launch endpoint (target_link_uri parameter).
  • The Proctoring Tool then creates an authentication request which it sends back to the Assessment Platform along with the identity of the tool (client_id parameter), the identity of the user (the login_hint as received above) and a number of other protocol parameters as defined in [SEC-10] and [OPENID-CCORE].
  • Finally, the Assessment Platform passes control back to the Proctoring Tool using an auto-submitted POST request containing the authentication response along with the full set of claims for the Start Proctoring message defined in this specification.

Although this flow is more complex than a simple signed URL or form POST the additional steps are required to mitigate the threat posed by an attacker initiating a session with the Assessment Platform in their own browser and then transferring that session to the victim's browser, thereby tricking the victim in to taking the assessment on their behalf (the so-called “Login-CSRF” [OWASP-CSRF] attack).

3.2 Proctoring Tool User Experience

The Proctoring Tool entirely controls the user experience for interacting with the Proctor or automated proctoring tools.  The tool may go through a number of technical and environmental checks the scope of which is likely to go beyond the user's current browser and may include an audit of the user's device and their surrounding environment.

The identity of the user that logged in to the Assessment Platform is passed to the Proctoring Tool in the Start Proctoring message.  The only required identity attributes are the Issuer (iss) and the Subject (sub) claims.  The Subject is an opaque identifier within the Assessment Platform.

The Proctoring Tool may endeavour to verify the identity of the candidate (the logged in user), by asking the them to present a government issued document to their webcam, asking them to answer special identity questions, or by more sophisticated means.  The methods used by the Proctoring Tool to verify identity claims are beyond the scope of this specification.

Identity verification is not required by this specification, the Proctoring Tool may simply record the candidate's identity by collecting attributes such as a webcam picture, details from any ID document presented, their answers to simple demographic questions, acceptance of rules of conduct, and so on.  This information could be compared with the information held on file by the Assessment Platform at a later date.

The Proctoring Tool may reject the candidate's request to launch the assessment aborting the workflow if the candidate fails to meet the proctoring requirements.  For example, the candidate may not be in a suitable environment or they may be unable to present a satisfactory identity document.

3.3 Transferring the Candidate Back to the Assessment Platform

Once the Proctoring Tool is satisfied that the assessment session is being proctored securely it transfers the candidate's browser back to the Assessment Platform using the Start Assessment message.

The Proctoring Tool transfers the candidate back to the Assessment Platform using the Tool-Originating Messages protocol defined in [SEC-10].  This is a single HTTP POST of a JWT payload containing the Start Assessment message.

The message_type of this new message has a value of LtiStartAssessment.

The URL used for the Start Assessment message MUST be sent to the Proctoring Tool by the Assessment Platform in the Start Proctoring message (see the assessment_start_url property of the https://purl.imsglobal.org/spec/lti-ap/claim/assessment_proctoring_settings claim).

The Assessment Platform MUST also include some session-specific data ( session_data) that is opaque to the Proctoring Tool in the Start Proctoring message.  This will be returned in the Start Assessment message and acts as an anti-CSRF token, the Assessment Tool MUST verify that this data matches the expected browser session before actually starting the assessment.

The tool MUST only redirect the user's browser to the assessment_start_url if it is satisfied that the assessment may proceed.  If the Candidate is unable to proceed with the test for any reason then the Proctoring Tool SHOULD use the return_url property of the https://purl.imsglobal.org/spec/lti/claim/launch_presentation claim to redirect the Candidate back to the Assessment Platform with appropriate error information.

Although [SEC-10] implies that Tool-Originating messages “do not assert the user identity” this this specification extends this protocol with additional claims to ensure that the Assessment Platform can determine which of the optional identity claims it provided in the Start Proctoring message have been verified by the Proctoring Tool (see below).

To ensure that the role of the Proctoring Tool in any identity verification process is unambiguous any optional user identity claims provided by the Assessment Platform in the Start Proctoring message that have been verified by the Proctoring Tool SHOULD be included in the subsequent Start Assessment message.  Unverified claims MUST NOT be included.

For example, if a Proctoring Tool verifies the candidate's identity by examining a passport presented to a webcam and the Assessment Platform provided a family_name claim in the Start Proctoring message then the Proctoring Tool SHOULD verify that the candidate has that family name (by examining the passport) and echo the family_name claim back in the Start Assessmentmessage.  In contrast, if the Assessment Platform provides an address claim in the Start Proctoring message the Proctoring Tool MUST NOT return the address claim in the Start Assessment message because the candidate's passport does not contain verified address information.

An Assessment Platform MAY reject the Start Assessment message if a required identity claim is missing (indicating that it has not been verified by the Proctoring Tool).  Which identity claims a Proctoring Tool will verify is subject to agreement outside of the scope of this specification but, at a minimum, it is recommended that Proctoring Tools performing identity verification are able to verify the given_name, family_name and name claims.

3.4 Proctor Actions

During the assessment the Proctoring Tool may wish to communicate with the Assessment Platform directly, that is not through the browser session, to control the progress of the assessment.  For example, if a proctor observes a candidate talking on their mobile phone during their assessment the proctor might be instructed to terminate the assessment.  To achieve this, the Assessment Platform may optionally expose an Assessment Control Service endpoint in the Start Proctoring message that would allow the Proctoring Tool to issue control messages to the Assessment Platform such as pause and stop.

Service calls are secured according to the requirements of section 1.8 of [LTI-13] Interacting with Services. The security protocol is summarized in this extract from that document:

Access tokens MUST protect all the services described by the platform; tools MUST retrieve these access tokens using the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants as specified in the LTI Security Framework - Using JSON Web Tokens with OAuth 2.0 [SEC-10].

The access token endpoint is communicated during the tool registration and used to access all services (unless explicitly stated otherwise in the service definition).

Service calls also include the session data claim received in the Start Proctoring message to identify the assessment session that is subject to the control message.

4. Assessment Proctoring Messages

LTI platforms and tools use messages to transfer the user agent from one host to the other through an HTML form POST redirection containing the message payload.  The Assessment Proctoring specification defines a bi-directional workflow using both Platform-Originating messages and Tool-Originating messages:

  • The Start Proctoring message flows from the Assessment Platform to the Proctoring Tool to initiate the proctoring of the candidate
  • The Start Assessment message flows from the Proctoring Tool back to the Assessment Platform to authorize the candidate to start taking the assessment
  • The End Assessment message flows from the Assessment Platform back to the Proctoring Tool to allow the Proctoring Tool to perform closeout tasks post completion of the assessment

In addition to the the three new messages defined by this specification guidance is given on how the Proctoring Tool SHOULD behave in response to the unidirectional LtiResourceLinkRequest message defined by [LTI-13].

4.1 General Message Details

4.1.1 lti_message_hint login parameter

The Assessment Platform MAY use the optional lti_message_hint parameter defined by [LTI-13].  If provided, the Proctoring Tool MUST include this parameter (and the login_hint) in the authentication request sent as part of the OpenID Connect workflow used to transfer the user to the Proctoring Tool with the Start Proctoring message.

4.1.2 JSON Web Token

As with the core resource link launch request, the Start Proctoring and End Assessment messages are sent as an OpenID Token whereas the Start Assessment message is sent as a plain JSON Web Token (JWT) [RFC7519]. For details on the process by which message senders encode messages into JWTs, see the 1EdTech Security Framework specification [SEC-10].

4.1.3 Message claims

All three proctoring message types consist of a set of claims that supplement the ones mandated by the 1EdTech Security Framework [SEC-10] specification.  Additionally, many of the claims defined here are reused from the LTI resource link launch request.  For full details of those claims refer to [LTI-13].

For forwards compatibility receivers of messages MUST ignore any claims in messages they do not understand and not treat the presence of such claims as an error.

4.1.3.1 Message type and schemes

Each proctoring message's https://purl.imsglobal.org/spec/lti/claim/message_type claim value declares the appropriate message type.  Both proctoring message types have associated JSON schemas that formally define all their claims, which claims are required, and which are optional.

Name Message type value Schema
Start Proctoring Message LtiStartProctoring
Start Assessment Message LtiStartAssessment
End Assessment Message LtiEndAssessment

4.2 Start Proctoring Message

This section describes the composition of the Start Proctoring message.  This message is used to trigger the workflow that launches a proctored assessment.  Prior to this message the candidate will have logged in to the Assessment Platform and established a session with it in their browser.  When the candidate indicates that they are ready to take the assessment, for example by clicking a “Launch Exam” button, the Assessment Platform transfers the candidate's browser session to the Proctoring Tool using the OpenID connect workflow as described above ultimately sending the Start Proctoring message.

4.2.1 Required Message Claims

4.2.1.1 Message type claim

Ad defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/message_type claim must have the value LtiStartProctoring.

4.2.1.2 LTI version claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/version claim must have the value 1.3.0.

4.2.1.3 Deployment ID claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/deployment_id claim identifies the platform-tool integration governing the message.

4.2.1.6 Attempt number claim

The https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number claim MUST specify the candidate's attempt number.  Used in conjunction with the resource link claim this information can be used by the Proctoring Tool to determine if the candidate is starting a new attempt at the assessment or is returning to resume a previous attempt.  The value SHOULD be simple integer with the first attempt having attempt number 1. This will be passed as an integer in the JWT claim.

This specification imposes no limits on the number of times a Candidate can initiate the proctoring process for a given attempt at an assessment.  A Proctoring Tool MAY impose a limit of one successful launch per assessment (resource_link) per user.  Multiple attempts at the same assessment SHOULD NOT be assumed without prior arrangement with the Proctoring Tool.

Example 4.2.3.6.1: the Candidate initiates the exam launch workflow and is transferred to the Proctoring Tool.  Once connected with the proctor they are asked to present their government issued ID document but are unable to provide anything suitable.  They return the following day and initiate the exam launch workflow a second time.  The Assessment Platform sends the sameattempt number in both Start Proctoring messages.

Example 4.2.3.6.2: the Candidate initiates the assessment launch workflow for their first attempt at their certification exam.  The Assessment Platform sets the attempt number to 1 in the Start Proctoring message.  The proctor is satisfied that the candidate's environment is secure and the candidate is allowed to start the assessment.  The candidate fails the exam and returns one month later.  When they initiate the launch workflow again the Assessment Platform sends attempt number 2.

4.2.1.7 User identity claims

Since the Start Proctoring message is a platform-originating message [SEC-10] the user identity is contained the corresponding Open ID Token.  Refer to [OPENID-CCORE] for a full list of permitted attributes.  The only required identity attributes are the Issuer (iss) and the Subject (sub) claims.

sub (required): the sub (Subject) MUST be a stable, locally unique to the iss (Issuer), identifier for the actual, authenticated candidate that initiated the launch.

given_name (recommended): the given/first name(s) of the candidate.  Names may contain space separators.

family_name (recommended): the surname/last name(s) of the candidate.  Names may contain space separators.

name (recommended): the candidate's full name in displayable form.

email (optional): the candidate's email address.  The Proctoring Tool should ignore this value unless email_verified is also provided and is true.

email_verified (optional): whether or not the Assessment Platform has verified the candidate's email address.

picture (optional): the picture claim is defined to be an image file that SHOULD reference a profile photo of the user and SHOULD NOT be an arbitrary photo taken or provided by the end-user.  Given this uncertainty the Proctoring Tool MUST NOT use this picture for identification purposes except by prior arrangement with the Assessment Platform.

locale (optional): the Assessment Platform SHOULD use the locale attributed defined in the launch presentation claim to indicate the candidate's preferred locale instead of this attribute.  The Proctoring Tool is not required to support multiple locales and MUST NOT treat an unknown or unsupported locale as an unsuccessful launch.

Further information about the user may be provided in associated claims defined in the OpenID Connect Core specification [OPENID-CCORE] such as gender,   birthdate, address etc.  In the interests of minimizing the personal information exposed by the Assessment Platform any additional fields SHOULD only be included when the Proctoring Tool is known to require them for ID verification.

4.2.1.8 Roles claim

As defined in the LTI Core specification [LTI-13], the https://purl.imsglobal.org/spec/lti/claim/roles claim is required but MAY be empty.  The Start Proctoring message always initiates the proctoring process (and corresponding assessment launch) regardless of any value specified for this claim, the Proctoring Tool MUST ignore this value.  If the Assessment Platform provides a non-empty value it SHOULD include http://purl.imsglobal.org/vocab/lis/v2/membership#Learner.

4.2.1.9 Start assessment url claim

Once the Proctoring Tool has secured the candidate's environment and performed any required identity checks successfully it transfers the browser session back to the Assessment Platform with the Start Assessment message.  This message is sent to the URL provided in the required https://purl.imsglobal.org/spec/lti-ap/claim/start_assessment_url claim.

4.2.1.10 Session data claim

The required https://purl.imsglobal.org/spec/lti-ap/claim/session_dataclaim contains data that is opaque to the Proctoring Tool but MUST be stored and sent to the Assessment Platform when transfering the candidate's browser back with the Start Assessment message.

The data in this claim provides an important defence against CSRF attacks against the Assessment Platform and MJST be chosen in a way that makes it suitable for use as an anti-CSRF token.

4.2.2 Optional Message Claims

Start Proctoring messages MAY contain any of the following claims.  Each group of claims is defined using its own JSON Schema.

4.2.2.1 Context claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/context claim composes properties for the platform context from within which the Start Proctoring message was sent.  The context typically represents a course or course section.

Although optional, the context may be useful and even required by some Proctoring Tools as it provides a grouping or cohort of Candidates that can be helpful when analyzing data captured during the proctoring process.  If the context claim is present, the only required attribute is id.

4.2.2.2 Platform instance claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/tool_platform claim composes properties associated with the platform initiating the launch.  An example is given in the Appendix.

4.2.2.3 Launch presentation claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/launch_presentation claim SHOULD be used to provide a return_url for use when the the Proctoring Tool needs to reject the Candidate's request to start the test (using the lti_errormsg and lti_errorlog parameters).

The document_target, height and width properties SHOULD NOT be specified, if specified the document_targetMUST be set to window.

The optional locale property SHOULD be used to indicate the user's preferred language for communication with the Proctoring Tool, including the preferred language for communicating with a live proctor.  If not provided, the locale claim defined by OpenID Connect Core [OPENID-CCORE] MUST be used instead (but note the uncertainty around the format of that value).  If neither are provided then a default locale for the Proctoring Tool MUST be used.  The Proctoring Tool MUST NOT treat an unknown or unsupported locale as an unsuccessful launch.

4.2.2.4 Learning Information Services (LIS) claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/lis claim composes properties that correspond to values otherwise obtainable from a Learning Information Services (LIS) endpoint. The use of LIS in conjunction with Assessment Proctoring is NOT recommended.

4.2.2.5 Custom properties and variable substitution claim

Custom properties allow a message sender (in this case, the Assessment Platform) to send key-value pairs defined outside of this specification.  There are no custom properties defined in this specification and no defined variable substitutions.  The Proctoring Tool MUST ignore any unrecognized custom properties that it does not understand.

4.2.2.6 Assessment control service claim

During the assessment the Proctoring Tool may need to send a service message to the Assessment Platform to control the assessment in response to an incident detected by the proctor.  These messages are sent directly to the Assessment Platform using the Assessment Control Service specified in the https://purl.imsglobal.org/spec/lti-ap/claim/acs claim.  Support for Assessment Control Service is optional, an Assessment Platform is not required to provide a service endpoint and a Proctoring Tool is not required to use it if it is provided.

assessment_control_url (required): the URL of the Assessment Control Service endpoint.

actions (required): an array of the actions supported by the service.  An array of values as defined by the action parameter of the service request object (see below).

4.2.2.7 Proctoring settings claim

The optional https://purl.imsglobal.org/spec/lti-ap/claim/proctoring_settings claim has the following properties:

data (optional): an opaque value which is tool-specific and can be interpreted as controlling settings not defined elsewhere

4.3 Start Assessment Message

The Start Assessment message covers the last part of the overall assessment launch workflow: once the Proctoring Tool's controls are in place the Proctoring Tool transfers the candidate's browser session back to the Assessment Platform.

The Start Assessment message follows the protocol for Tool-Originating Messages [SEC-10] and comprises a signed JWT using the JSON Web Signature (JWS) defined in [RFC7515].  The JWT is sent via an HTTP POST with a single required parameter: JWT.  To prevent CSRF attacks against the Assessment Platform the JWT contains the session_data set by the Assessment Platform in the Start Proctoring message.  This data, opaque to the Proctoring Tool, acts as an anti-CSRF token.

The Proctoring Tool MUST ensure that the Start Assessment message is sent in the same browser session as the Start Proctoring message.  The Proctoring Tool MUST NOT require the candidate to clear cookies, reset their browser, open a private browsing window, or any similar action that disrupts the browser session.

4.3.1 Required Message Claims

4.3.1.1 Message type claim

Ad defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/message_type claim must have the value LtiStartAssessment.

4.3.1.2 LTI version claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/version claim must have the value 1.3.0.

4.3.1.3 Deployment ID claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/deployment_id claim identifies the platform-tool integration governing the message.

4.3.1.4 Session data claim

The required https://purl.imsglobal.org/spec/lti-ap/claim/session_dataclaim contains the value sent to the Proctoring Tool in the Start Proctoring message.  The data in this claim provides an important defence against CSRF attacks against the Assessment Platform: the Assessment Tool MUST validate this value against the user's browser session before allowing them to start the assessment.

4.3.1.6 Attempt number claim

The https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number claim specifies the candidate's attempt number, as set by the Assessment Platform.  The Proctoring Tool MUST copy this value to the Start Assessment message unchanged.

4.3.1.7 End assessment return claim

When the The optional https://purl.imsglobal.org/spec/lti-ap/claim/end_assessment_return claim value is a Boolean that should be set to true if the Proctoring Tool wishes the Assessment Platform to call the LTIEndAssessment message to the Proctoring Tool placement after the assessment has been submitted. If this is not set or is set to false the Assessment Platform will follow it's normal post completion flow.

4.3.2 Optional Message Claims

4.3.2.1 Verified user claim

The optional https://purl.imsglobal.org/spec/lti-ap/claim/verified_userclaim is used to indicate which of the user's attributes passed in the Start Proctoring message have been verified by the Proctoring Tool.  Verification does not mean merely recorded but confirmed (by automated means or manual inspection) as matching the values sent by the Assessment Platform within the limits of the methods supported by the proctoring tool itself.  The iss and sub attributes SHOULD NOT be included as they are opaque to the Proctoring Tool and cannot be independently verified.

If the picture attribute is provided it MUST point to a picture taken by the Proctoring Tool.  It MUST NOT be the same picture provided by the Assessment Platform in the Start Proctoring message.  The Proctoring Tool MAY include this picture even if the Assessment Platform did not provide a URL for the user's profile picture in the Start Proctoring message.  

4.4 End Assessment Message

The End Assessment message covers the last part of the overall assessment submission workflow. This message type MUST be called by the Assessment Platform upon attempt completion IF the end_assessment_return claim is set to true as part of the Start Assessment launch. If the assessment needs to close due to an error NOT handled by the Assessment Platform that error MUST be passed along using the LtiEndAssessment message and the errormsg and errorlog claims. The message utilizes the OpenID connect workflow prior to sending the message.

4.4.1 Required Message Claims

4.4.1.1 Message type claim

Ad defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/message_type claim must have the value LtiEndAssessment.

4.4.1.2 LTI version claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/version claim must have the value 1.3.0.

4.4.1.3 Deployment ID claim

As defined in the LTI Core specification [LTI-13], the required https://purl.imsglobal.org/spec/lti/claim/deployment_id claim identifies the platform-tool integration governing the message.

4.4.1.5 Attempt number claim

The https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number claim MUST specify the candidate's attempt number.  Used in conjunction with the resource link claim this information can be used by the Proctoring Tool to determine if the candidate is starting a new attempt at the assessment or is returning to resume a previous attempt.  The value SHOULD be simple integer with the first attempt having attempt number 1.

This specification imposes no limits on the number of times a Candidate can initiate the proctoring process for a given attempt at an assessment.  A Proctoring Tool MAY impose a limit of one successful launch per assessment (resource_link) per user.  Multiple attempts at the same assessment SHOULD NOT be assumed without prior arrangement with the Proctoring Tool.

4.4.1.6 User identity claims

Since the End Assessment message is a platform-originating message [SEC-10] the user identity is contained the corresponding Open ID Token.  Refer to [OPENID-CCORE] for a full list of permitted attributes.  The only required identity attributes are the Issuer (iss) and the Subject (sub) claims.

sub (required): the sub (Subject) MUST be a stable, locally unique to the iss (Issuer), identifier for the actual, authenticated candidate that initiated the launch.

given_name (recommended): the given/first name(s) of the candidate.  Names may contain space separators.

family_name (recommended): the surname/last name(s) of the candidate.  Names may contain space separators.

name (recommended): the candidate's full name in displayable form.

email (optional): the candidate's email address.  The Proctoring Tool should ignore this value unless email_verified is also provided and is true.

email_verified (optional): whether or not the Assessment Platform has verified the candidate's email address.

picture (optional): the picture claim is defined to be an image file that SHOULD reference a profile photo of the user and SHOULD NOT be an arbitrary photo taken or provided by the end-user.  Given this uncertainty the Proctoring Tool MUST NOT use this picture for identification purposes except by prior arrangement with the Assessment Platform.

locale (optional): the Assessment Platform SHOULD use the locale attributed defined in the launch presentation claim to indicate the candidate's preferred locale instead of this attribute.  The Proctoring Tool is not required to support multiple locales and MUST NOT treat an unknown or unsupported locale as an unsuccessful launch.

Further information about the user may be provided in associated claims defined in the OpenID Connect Core specification [OPENID-CCORE] such as gender,   birthdate, address etc.  In the interests of minimizing the personal information exposed by the Assessment Platform any additional fields SHOULD only be included when the Proctoring Tool is known to require them for ID verification.

4.4.1.7 Roles claim

As defined in the LTI Core specification [LTI-13], the https://purl.imsglobal.org/spec/lti/claim/roles claim is required but MAY be empty.  The End Assessment message allows for close-out of the proctoring process regardless of any value specified for this claim, the Proctoring Tool MUST ignore this value. If the Assessment Platform provides a non-empty value it SHOULD include http://purl.imsglobal.org/vocab/lis/v2/membership#Learner.

4.4.2 Optional Message Claims

End Assessment messages MAY contain any of the following claims. Each group of claims is defined using its own JSON Schema.

4.4.2.1 Context claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/context claim composes properties for the platform context from within which the End Assessment message was sent.  The context typically represents a course or course section.

Although optional, the context may be useful and even required by some Proctoring Tools as it provides a grouping or cohort of Candidates that can be helpful when analyzing data captured during the proctoring process.  If the context claim is present, the only required attribute is id.

4.4.2.2 Platform instance claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/tool_platform claim composes properties associated with the platform initiating the launch.

4.4.2.3 Launch presentation claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/launch_presentation claim SHOULD be used to provide a return_url for use when the the Proctoring Tool has finished its closeout tasks.

The document_target, height and width properties SHOULD NOT be specified, if specified the document_targetMUST be set to window.

The optional locale property SHOULD be used to indicate the user's preferred language for communication with the Proctoring Tool, including the preferred language for communicating with a live proctor.  If not provided, the locale claim defined by OpenID Connect Core [OPENID-CCORE] MUST be used instead (but note the uncertainty around the format of that value).  If neither are provided then a default locale for the Proctoring Tool MUST be used.  The Proctoring Tool MUST NOT treat an unknown or unsupported locale as an unsuccessful launch.

Example 4.4.2.3.1: on completing a remotely-proctored assessment the Assessment Platform redirects the candidate's browser back to Proctoring Tool (via an LTI launch with the message type LtiEndAssessment assuming end_assessment_return was set to true in the Start Assessment launch). In response, the Proctoring Tool alerts the remote proctor who makes any required closing remarks to the candidate before disabling all automated monitoring of the candidate's device and terminating the remote video conference session. Finally, the Proctoring Tool redirects the candidate's browser back again to the Assessment Platform using the return_url given in the launch_presentation claim.  In response to this final redirect the Assessment Platform presents the candidate with an evaluation questionnaire to provide feedback to the Program Manager on their experience during the proctored assessment.

4.4.2.4 Learning Information Services (LIS) claim

As defined in the LTI Core specification [LTI-13], the optional https://purl.imsglobal.org/spec/lti/claim/lis claim composes properties that correspond to values otherwise obtainable from a Learning Information Services (LIS) endpoint. The use of LIS in conjunction with Assessment Proctoring is NOT recommended.

4.4.2.5 Custom properties and variable substitution claim

Custom properties allow a message sender (in this case, the Assessment Platform) to send key-value pairs defined outside of this specification.  There are no custom properties defined in this specification and no defined variable substitutions.  The Proctoring Tool MUST ignore any unrecognized custom properties that it does not understand.

4.4.2.6 Proctoring settings claim

The optional https://purl.imsglobal.org/spec/lti-ap/claim/proctoring_settings claim has the following properties:

data (optional): an opaque value which is tool-specific and can be interpreted as controlling settings not defined elsewhere

4.4.2.7 Error message claim

The optional https://purl.imsglobal.org/spec/lti-ap/claim/errormsg claim value is a plain text string of a message the Proctoring Tool may show to the end user upon return to the platform. It indicates some error as occurred during the interaction.

4.4.2.8 Error log claim

The optional https://purl.imsglobal.org/spec/lti-ap/claim/errorlog claim value is a plain text string of a message the Proctoring Tool may log when processing this message. It indicates some error as occurred during the interaction.

5. Assessment Control Service

An Assessment Platform MAY provide support for the Assessment Control Service (ACS).  An Assessment Platform indicates support for the ACS by passing the endpoint and details of the service to the Proctoring Tool in the Start Proctoring message in the https://purl.imsglobal.org/spec/lti-ap/claim/acs claim.

The ACS allows the Proctoring Tool to send messages to the Assessment Platform either during the assessment (in the case of Pause or Terminate commands) or afterwards to flag the result for further review.

All requests to the ACS MUST be secured by including a properly scoped access token in the Authorization header as per the 1EdTech Security Framework [SEC-10].  This requires the Proctoring Tool to obtain an access token from the Assessment Platform's OAuth2 authorization server prior to making service calls.  When requesting an access token the scope of the token must be specified.  This specification defines a single scope: https://purl.imsglobal.org/spec/lti-ap/scope/control.allthat MUST be used in all client authentication requests.

The Proctoring Tool may retain the assessment_control_url, resource_link and attempt_number received in the Start Proctoring message and call the service at any time, even after the assessment session has ended.  This allows the Proctoring Tool to carry out more sophisticated analysis of the data collected for a group of Candidates or even to record information for later subjective review flagging a result in response to an incident identified after the fact by a human reviewer.  The Assessment Platform MUST accept requests to the ACS that pertain to completed assessment sessions for as long as it remains reasonable to update information about the conduct of that session.

All requests to the ACS must use HTTP POST with the following media type: application/vnd.ims.lti-ap.v1.control+json.  The body of the request is a simple JSON object with parameters defined in the following sections.  The Assessment Platform MUST ignore any unknown parameters passed to the ACS.

The Assessment Platform MUST return an HTTP status code of 200 if the request conforms to this specification, the user, resource_link and attempt_number correspond to a valid assessment attempt and the requested action is supported.  The body of the response must also be of media type: application/vnd.ims.lti-ap.v1.control+json.  The response object JSON object contains information about the current status of the attempt.

5.1 Required Request Parameters

5.1.1 user parameter

An object that identifies the candidate using the data passed to the Proctoring Tool in the Start Proctoringmessage.

iss (required): the issuer identifier from the OpenID token describing the Assessment Platform that issued the user identity.

sub (required): the subject identifier from the OpenID token describing the user authenticated with the Assessment Platform.

5.1.3 attempt_number parameter

The attempt number copied from the Start Proctoring message.  Together with the resource_link and user objects the attempt_number uniquely identifies the candidate's assessment.  A Proctoring Tool MAY receive multiple Start Proctoring messages for the same user, assessment and attempt, for example, if the launch flow was aborted following a technical failure.  The ACS does not differentiate between multiple launches (if any): all control messages relating to the attempt are identified solely by these three require parameters.

5.1.4 action parameter

The action parameter instructs the Assessment Platform which action to take in relation to the candidate's assessment attempt.  If the attempt is not in a statue compatible with the requested action the Assessment Platform MUST accept the request and indicate that no action was taken by returning the appropriate status in the response (see below).

The following values are permitted.

pauseRequest to pause a running attempt.  While the attempt is paused the candidate SHOULD NOT be able to review the questions, enter responses or otherwise interact with the assessment.  The behavior of the Assessment Platform when pausing timed assessments is not defined by this specification.

resumeRequest to resume a previously paused attempt.

terminateRequest to terminate an assessment attempt.

updateA special value indicating that the status of the attempt should be updated based only on the additional parameters, such as adding extra time or recording a message from the proctor.  The Proctoring Tool MAY also use this action to poll the ACS for the current status of the attempt.

flagRequest to flag an attempt.  A flag may be placed on an attempt at any time and indicates the need to review the candidate's session to ensure that the session was conducted fairly.  The reason for flagging is given in the optional reason_code and reason_msg parameters.

5.1.5 incident_time parameter

The timestamp of the incident that caused this request.  This MAY differ from the time of the request itself, for example, a Proctoring Tool may perform analysis of video data captured during the assessment session at a later time.  If an incident is identified in the video data the incident_time is the timestamp of the incident, not the time at which the video analysis system identified it.

5.1.6 Optional Request Parameters

The following optional parameters may be added to any of the control message actions.  If an Assessment Platform receives a parameter that

5.1.7 extra_time parameter

The extra_time  parameter, given in minutes, is used to add time to a timed assessment.  For example, this may be used to compensate a candidate for an incident that was out of their control or to implement some other form of permitted accommodation identified by the Proctor.

This represents the total amount of extra time granted for this session. If the Tool received multiple extra time messages, the most recent represents the amount of time granted.

5.1.8 incident_severity parameter

The incident_severity parameter is a numeric parameter indicating the severity of the incident that triggered the request.  The value MUST be in the range 0 to 1 with 0 indicating very low severity and 1 indicating very high severity.  For example, if a live Proctor observes the candidate making a call on their mobile telephone they might pause the assessment and use a high value for the severity.

The following severity mapping is non-normative but MAY be used when displaying information about an incident to a Reviewer.  A value less than 0.25 - information only, green flag incident; a value less than 0.75 but greater than or equal to 0.25 - warning, amber flag; value greater than or equal to 0.75 - severe, red flag.

5.1.9 reason_code parameter

The reason_code is an optional string (a URN or URI could be used) indicating the reason for the request.  The values of these codes are Proctoring Tool-specific.

5.1.10 reason_msg parameter

The reason_msg is an optional text string describing the reason for the request in a human-readable form.  For example, the value may be a comment entered by a live proctor or a message generated by an automated system.

5.2 Response Parameters

5.2.1 status parameter

The status parameter informs the Proctoring Tool of the current status of the attempt and takes one of the following values:

none: the attempt has not been started yet

running: the attempt is currently running.

paused: the attempt is currently paused

terminated:the attempt was terminated by the Proctoring Tool.

complete: the attempt is complete

5.2.2 extra_time parameter

The total amount of extra_timecurrently given to the candidate, in minutes.

6. Example Deployment and Messages

In the following example messages the Assessment Platform has an issuer id of https://assessment.org  - although this follows the guidance in [OPENID-CCORE] where it is RECOMMENDED that only a single issuer be defined per host, OpenID Connect does acknowledge that multi-tenanted systems may require multiple issuer ids per host.  For multi-tenanted Assessment Platforms (sharing the same host name) it is RECOMMENDED that Issuer ids and service endpoints are differentiated by path, e.g., https://assessment.org/tenant100.  The important thing is that the subject identifiers that represent end users of the Assessment Platform MUST be unique within the scope of the issuer id.  The Assessment Platform also has a public/private key corresponding to the issuer id.  

The Assessment Platform defines an Authorization Service endpoint for the purposes of OpenID Connect authorization flows at https://assessment.org/auth.  It also exposes an OAuth2 access token endpoint at https://assessment.org/tokens, the access token endpoint is used to obtain access tokens for the Assessment Control Service.

The Proctoring Tool defines two service endpoints: a login endpoint used to initiate the OpenID connect authorization flow: https://proctor.org/loginand a launch endpoint used to send the Start Proctoring message https://proctor.org/launch.  The tool also has its own public/private key associated with these endpoints.

Prior to the Assessment Launch Workflow the Proctoring Tool's endpoints and public key are used to create a new tool deployment in the Assessment Platform.  The Assessment Platform allocates a unique client_id to the Proctoring Tool, in the example that follows this value is ptool009.  The client id MUST be unique within the scope of the issuer id and service endpoints defined by the platform.  The client id, along with the issuer id, service endpoint URLs and platform public key are used to configure the Proctoring Tool and complete the trust relationship between the two systems.

The Assessment Platform also internally allocates a deployment id to the integration, see the Start Proctoring message above for more details but bear in mind that LTI supports a deployment model where the same Tool, using the same endpoints and public key, can be deployed multiple times within the Assessment Platform (for example, for different Assessment Programs managed by different Program Managers within the same institution).  In the examples that follow the deployment id allocated to this integration by the Assessment Platform is 23487.

6.1 Assessment Launch Workflow

The Assessment Platform initiates the workflow by directing the candidate's browser to issue a GET or POST request to the Proctoring Tools login endpoint.

POST https://proctoring.org/login
Content-Type: application/x-www-form-urlencoded

iss=https%3A%2F%2Fassessment.org&login_hint=22375&target_link_uri=
https%3A%2F%2Fproctoring.org%2Flaunch&lti_message_hint=398

The Proctoring Tool uses the iss parameter to identify the Assessment Platform and then performs an authentication request to the Assessment Platform's Authorization Service endpoint.  This is done using a redirect in the candidate's browser.

GET 
https://assessment.org/auth?client_id=ptool009&
login_hint=22375&lti_message_hint=398&nonce=562d5142d4932cb6ae01&
prompt=none&redirect_uri=https%3A%2F%2Fproctoring.org%2Flaunch&response_mode
=form_post&response_type=id_token&scope=openid&state=cmkVeQ

The state parameter contains opaque data created by the Proctoring Tool to track state across the OpenID connect flow and also plays the role of an anti-CSRF token binding the Assessment Platforms next response to the same browser session.  LTI requires the OpenID prompt parameter to be none indicating that no user interaction will take place in the Assessment Platform in response to this request.  Instead, the Assessment Platform verifies that the user indicated in the login_hint is logged in to the current browser session, confirms that the redirect_url matches the registered launch endpoint for the Proctoring Tool integration identified by the client_id and then returns the candidate to the Proctoring Tool with a POST back to the redirect_uri containing the detailed Start Proctoring message claims.

POST https://proctoring.org/launch
Content-Type: application/x-www-form-urlencoded
    
id_token=eyJhbGciOi...uDP6KuSMg&state=cmkVeQ

The state parameter is reflected back to the Proctoring Tool and MUST be validated to prevent CSRF attacks.

The id_token is a JWT signed using JWS [RFC7515] (abbreviated in the above example).  The value consists of three base64 encoded fields separated by '.' - the first is the JOSE header describing the algorithm used, the second is the plaintext payload and the third is the signature calculated using the Assessment Platform's private key.  The Proctoring Tool can verify the signature using the public key configured during deployment.  The first two fields are decoded here:

{"alg":"RS256","kid":"hf8Sisblt0zj0KhjY8oAIH0ylU2PuYwnegc8Y9vJq9g"}

{ 
 "iss": "https://assessment.org", 
 "aud": "ptool009",
 "sub": "2047534b3cc6d7086909", 
 "exp": 1548871170, 
 "iat": 1548870870,
 "nonce": "cc0d7b7f6cdc554bacc7",
 "https://purl.imsglobal.org/spec/lti/claim/message_type":
  "LtiStartProctoring",
 "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0",
 "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "23487",
 "https://purl.imsglobal.org/spec/lti/claim/target_link_uri":
  "https://proctoring.org/launch",
 "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
  "id": "398",
  "title": "Algebra I",
  "description": "Algebra I: End of module exam"
 },
 "https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number":
  1,
 "given_name": "Jane",
 "family_name": "Doe",
 "name": "Jane Doe",
 "https://purl.imsglobal.org/spec/lti/claim/roles": [
  "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner
 ],
 "https://purl.imsglobal.org/spec/lti-ap/claim/start_assessment_url":
  "https://assessment.org/examgo",
 "https://purl.imsglobal.org/spec/lti-ap/claim/session_data":
  "ZOG9BSUgweWxVMlB1WXduZWdjOFk5dkpxOWcif", 
 "https://purl.imsglobal.org/spec/lti/claim/context": { 
   "id": "115", 
   "label": "M01", 
   "title": "Math Part 1", 
   "type": [ 
     "CourseOffering" 
 ] 
 },
 "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": { 
  "document_target": "window", 
  "return_url": "https://assessment.org/home",
  "locale": "en-US" 
 },
 "https://purl.imsglobal.org/spec/lti-ap/claim/acs": { 
  "actions": [ 
   "terminate",
   "flag", 
   "update"
  ],
  "assessment_control_url": "https://assessment.org/acs"
 },
 "https://purl.imsglobal.org/spec/lti-ap/claim/proctoring_settings":
 {
  "data": "video=on,audio=on,screencapture=off"
  }
}

The Proctoring Tool validates this message according to the rules set out in [SEC-10] 5.1.3 Authentication Response Validation.

For the purposes of this example the Proctoring Tool starts an audio/video conference with the candidate and asks them to present government issued id and the candidate offers their passport to the webcam.  A live Proctor validates that the given and family names on the passport match those in the Start Proctoring message and that the passport photo is a good likeness of the person presenting the document!  Satisfied that the candidate's environment is secure the Proctoring Tool issues the Start Assessment message using an HTTP POST to the start_assessment_url.

POST https://assessment.org/examgo
Content-Type: application/x-www-form-urlencoded

JWT=eyJhbGciO...SkBN

As for the Start Proctoring message, the JWT is a signed token, for brevity only the payload is illustrated below.  Notice that the iss and aud parameters are reversed indicating that the message is being sent from the Proctoring Tool to the Assessment Platform.  The Proctoring Tool's private key is used to calculate the signature.

{ 
         "iss": "ptool009", 
         "aud": "https://assessment.org", 
         "exp": 1548871178, 
         "iat": 1548870878,
        "nonce": "c60cbd5dc4af7c57cbc7",
        "https://purl.imsglobal.org/spec/lti/claim/message_type":
                "LtiStartAssessment",
        "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0",
        "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "23487",
        "https://purl.imsglobal.org/spec/lti-ap/claim/session_data":
                "ZOG9BSUgweWxVMlB1WXduZWdjOFk5dkpxOWcif",
        "https://purl.imsglobal.org/spec/lti/claim/target_link_uri":
                "https://proctoring.org/launch",
        "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
                "id": "398"
        },
        "https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number":
                1,
        "https://purl.imsglobal.org/spec/lti-ap/claim/verified_user": {
                "given_name": "Jane",
                "family_name": "Doe"
                }
        "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": { 
           "document_target": "window", 
           "return_url": "https://proctor.org/stop",
                "locale": "en-US"
         }
}

At the end of the assessment the Assessment Tool checks what value it received from the Start Assessment JWT for end_assessment_return. If the value was true the Assessment Platform launches to the Proctoring Tool with the LtiEndAssessment message. The launch follows the same security protocol as the Start Proctoring message. The OIDC workflow preceding the message is not shown here because it mirrors the sample in the Start Proctoring message above. 

{ 
 "iss": "https://assessment.org", 
 "aud": "ptool009",
 "sub": "2047534b3cc6d7086909", 
 "exp": 1548871170, 
 "iat": 1548870870,
 "nonce": "cc0d7b7f6cdc554bacc7",
 "https://purl.imsglobal.org/spec/lti/claim/message_type":
  "LtiEndAssessment",
 "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0",
 "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "23487",
 "https://purl.imsglobal.org/spec/lti/claim/target_link_uri":
  "https://proctoring.org/launch",
 "https://purl.imsglobal.org/spec/lti/claim/resource_link": {
  "id": "398",
  "title": "Algebra I",
  "description": "Algebra I: End of module exam"
 },
 "https://purl.imsglobal.org/spec/lti-ap/claim/attempt_number":
  "1",
 "given_name": "Jane",
 "family_name": "Doe",
 "name": "Jane Doe",
 "https://purl.imsglobal.org/spec/lti/claim/roles": [
  "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner
 ],
 "https://purl.imsglobal.org/spec/lti/claim/context": { 
   "id": "115", 
   "label": "M01", 
   "title": "Math Part 1", 
   "type": [ 
     "CourseOffering" 
 ] 
 },
 "https://purl.imsglobal.org/spec/lti/claim/launch_presentation": { 
  "document_target": "window", 
  "return_url": "https://assessment.org/home",
  "locale": "en-US" 
 },
 "https://purl.imsglobal.org/spec/lti-ap/claim/proctoring_settings":
 {
  "data": "video=on,audio=on,screencapture=off"
 }
}

The Proctoring Tool terminates the video conference between the Proctor and Candidate and redirects the candidate's browser back to the return_url that it received in the End Assessment message.

GET https://assessment.org/home

6.2 Assessment Control

In the above example the Assessment Platform declares an endpoint for the Assessment Control Service and support for the “terminate”, “flag” and “update” actions.  Suppose that the proctoring system recorded the audio during the session and that this audio is processed later and a loud noise is detected that the candidate may have found disturbing.  The proctoring system decides to flag the disturbance using the Assessment Control Service.

Assuming the Proctoring Tool does not have a valid access token for the ACS the first request it makes is to the OAuth2 access token endpoint of the Assessment Platform.  The request takes the form of a JWT signed using the Proctoring Tool's private key (as per the Start Assessment message above) but the OAuth parameters follow a different pattern according to [RFC7523], see below for details.

POST https://assessment.org/tokens
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparam
s%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=eyJ...CQQ&scope=https%3A%2F%2Fpurl.imsglobal.org%2F
spec%2Flti-ap%2Fscope%2Fcontrol.all

The JWT encoded in the the client_assertion parameters is expanded here:

{
        "iss" : ""https://proctoring.org",
        "sub" : "ptool009",
        "aud" : ""https://assessment.org/tokens",
        "exp" : 1548873478,
        "iat" : 1548873178,
        "jti" : "4ad4d0962a24037c9b00b70ef4e949c3"
}

The iss value used is an issuer identifier for the Proctoring Tool.  The Assessment Platform does not need to be provided with this value during deployment, it is for information only.  The subject ( sub) is the client_id of the Proctoring Tool and the audience ( aud) MUST be set to the URL of the token service endpoint being used.  Finally, to mitigate against replay attacks a unique id is provided in the jti parameter.

The response to this message contains the access token that the Proctoring Tool can use to call the ACS directly.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
        "access_token" : "2YotnFZFEjr1zCsicMWpAA",
        "token_type" : "bearer",
        "expires_in" : 3600,
        "scope" : "https://purl.imsglobal.org/spec/lti-ap/scope/control.all"
}

Subsequent calls the ACS are then made using the access_token in the Authorization header.

The Proctoring Tool flags the noise event in the candidate's assessment attempt with a POST request to the ACS endpoint:

POST https://assessment.org/acs
Content-Type: application/vnd.ims.lti-ap.v1.control+json
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

{
        "user" : {
                "iss" : "https://assessment.org",
                "sub": "2047534b3cc6d7086909"
        },
        "resource_link": {
                "id": "398"
        },
        "attempt_number": 1,
        "action": "flag",
        "incident_time": "2018-02-01T10:45:33Z",
        "incident_severity": "0.1",
        "reason_code": "12056",
        "reason_msg": "Excessive background noise outside candidate control"}

7. Implementation Guidance

7.1 Deployment

To ease deployment it is RECOMMENDED that Proctoring Tools expose their login endpoint and launch endpoint URLs along with their public key when provisioning the tool (or a tenant on multitenant tool).

It is further RECOMMENDED that the Assessment Platform is used to drive the deployment process.  The system administrator or other authorized person might use a user interface that accepts the Proctoring Tool's URLs and public key as inputs and provides the client_id and the platform's public key in return along with the issuer id, authorization endpoint and token endpoint URLs.

Finally, the Proctoring Tool administrator can add these details using a similar interface in the Proctoring Tool to complete the trust relationship between the two systems.

7.2 Assessment Tools and Learning Management Systems

Some Assessment Platforms play the role of an LTI Tool in an LMS/Assessment Tool relationship.  For LTI 1.3 this means the LMS must play the role of OpenID Provider to the Assessment Tool/Platform while, simultaneously, the Assessment Tool/Platform plays the role of OpenID Provider to the Proctoring Tool.

The Assessment Platform cannot pass the OpenID service endpoints and issuer information it receives from the LMS to the Proctoring Tool as LTI does not support simple delegation of the OP function.  In particular, the OP MUST redirect the candidate's browser to the Proctoring Tool using the full Start Proctoring message encapsulated in the id_token: a role that the LMS would not be able to fulfil.

7.3 Proctoring Controls

A. Use Cases

This section is non-normative.

Use Case Title: Launch the Assessment
Use Case Local ID: Proctoring-01/In-Session
Brief Description: Launch the assessment through the proctoring service
Level: Primary Task
Actors: Primary:Candidate
Secondary:
Preconditions: Assessment is available with proctoring tool enabled, all pre-registration and scheduling requirements have been satisfied
Triggers: Candidate made aware that assessment is now due
Basic Flow of Events: Candidate launches a  proctored assessment in the Assessment Platform.  Proctoring Tool launches and once proctoring arrangements are in place and any ID checks completed the candidate is returned to the Assessment Platform to launch the assessment.
Alternative Flows: Candidate launches the assessment to review previously completed assessment under proctored conditions

The following use case is documented for completeness.  The protocol documented by this specification does not cover the method by which the Proctoring Tool is made active for an assessment within the Assessment Platform.

Use Case Title: Add Proctoring Requirement
Use Case Local ID: Proctoring-02/Pre-Exam
Brief Description: Add proctoring requirement to an assessment.
Level: Primary Task
Actors: Primary:Assessment Administrator (may be Instructor);
Secondary:Program Manager/Administrator
Preconditions: Assessment is available within the Assessment Platform system
Triggers: Assessment has been created ready for scheduling
Basic Flow of Events: Assessment Administrator makes  assessment available, e.g., as a resource (with optional context) within the Assessment Platform,  enables the Proctoring Tool for use in conjunction with this assessment before opening it to candidates

The following use case presupposes that the Proctor is able to interact with the Proctoring Tool through their own device.  This does not exclude local 'in person' proctoring as a local proctor may still have access to a device used to manage the assessment session.  A local proctor may also be able to intervene directly, e.g., by powering off the Candidate's computer to prevent them cheating or stealing assessment content.

Use Case Title: Proctor intervenes
Use Case Local ID: Proctoring-03/In-Session
Brief Description: Control a running assessment to protect integrity of the process
Level: Sub-function
Actors: Primary:Proctor
Secondary:Candidate
Preconditions: Candidate is currently taking an assessment launched through the proctoring tool (Proctoring-08/In-Session)
Triggers: An exceptional event occurs during the candidate's assessment that requires that the session be paused or terminated.
Basic Flow of Events: Proctor opens a control panel for the Candidate's assessment in the Proctoring Tool; proctor uses controls to pause, terminate or add extra time to the candidate's test.  Candidate's test may be aborted and they are returned to an appropriate page in the assessment platform.
Alternative Flows: Candidate's test is resumed and they continue with the assessment (incident is noted in audit log)
Notes: Optional as only some assessment systems provide this type of capability.  Split out: automated flagging in real time of issues detected by proctoring service as an alternative (and/or) way of controlling running tests.

Most Proctoring Tools do some form of technical system checking process to ensure that the necessary software and hardware is available during the assessment launch.  In addition to these just-in-time checks some Proctoring Tools provide a way for candidates to 'dry run' their technology well in advance of the scheduled assessment to give them plenty of time to install required software or change system configuration.  This use case refers to these advanced checks only.

Use Case Title:  Validate User System
Use Case Local ID: Proctoring-04/Pre-Exam/In-Session
Brief Description: Check technology requirements for a specific PC, laptop or other device prior to the scheduled assessment time
Level: Sub-function
Actors: Primary:Candidate
Secondary:Test Center Administrator
Preconditions: Assessment is available with proctoring tool enabled in the platform.
Triggers: Candidate made aware that assessment is available
Basic Flow of Events: Candidate launches a proctored assessment through the assessment resource in the platform and is presented with technical requirements and system diagnostics suitable for checking that their device is suitable for taking the assessment
Alternative Flows: Candidates may also complete this step before assessment is available.
Notes: This could be implemented as an extension to any platform systemcheck.  Would typically be implemented as a launch into the proctoring tool.
Use Case Title: Site-wide Proctoring Options
Use Case Local ID: Proctoring-05/Pre-Exam
Brief Description: Configure proctoring options that will apply to all assessments delivered within the institution.
Level: User
Actors: Primary:Program Manager/Administrator;
Secondary:Examinations Officer, Academic Integrity Officer
Preconditions: Proctoring tool provider is already registered with a platform system using LTI.
Triggers: After initial provisioning of the proctoring tool; following reviews of testing program performance and policies
Basic Flow of Events: The administrator launches into the proctoring tool to be able to set platform system wide settings.
Notes: Some proctoring tools may not support any customization at this level so this use case is optional.
Use Case Title: Assessment Specific Proctoring Options
Use Case Local ID: Proctoring-06/Pre-Exam
Brief Description: Modify default  proctoring options for an individual assessment
Level: Sub-function
Actors: Primary:Assessment Administrator (may be Instructor)
Secondary:Program Manager/Administrator
Preconditions: Assessment is available within the platform system and proctoring tool has been enabled for it
Triggers: Assessment has proctoring enabled
Basic Flow of Events: Test Administrator launches the proctoring tool for the assessment resource and is able to control options provided by that tool.  
Notes: Optional, some systems may not support configuration options.
Use Case Title: External Reviewer Launch of Proctoring System
Use Case Local ID: Proctoring-07
Brief Description: Review audit information for entire assessment program
Level: Sub-function
Actors: Primary:Reviewer
Secondary:Examinations Officer, Academic Integrity Officer
Preconditions: One or more candidates have completed an assessment with proctoring tool
Triggers: Assessment session ended; routine audit requirement or incident response
Basic Flow of Events: Reviewer launches the proctoring tool from the consumer (no context required) and is presented with all audit information collected by the proctoring tool.

B. Use Cases Placed Out Of Scope

This section is non-normative.

These use cases were documented but voted out of scope by workgroup participants for the first version of this specification. These and other new use cases will be considered for future iterations.

Use Case Title: External Proctor Launch of Proctoring System
Use Case Local ID: Proctoring-08/In-Session
Brief Description: Users in the consumer system (e.g., LMS) act as (live - but online) proctors in the proctoring tool if agent is providing their own proctors
Level: Primary Task
Actors: Primary:Proctor
Secondary:
Preconditions: Proctoring tool has been provisioned in the consumer
Triggers: Proctor comes on shift or is notified of a pre-arranged time for a remote proctoring session they are scheduled to proctor.
Basic Flow of Events: Proctor launches the proctor tool from the consumer system (no context necessary) and is able to use the proctoring tool to remotely proctor a candidate taking an assessment.
Alternative Flows: Proctor launches the proctor tool from an assessment resource in the consumer system made available with proctoring enabled and is able to proctor a candidate taking that assessment
Use Case Title: External Reviewer Launch of Proctoring System (limited)
Use Case Local ID: Proctoring-09/Post-Exam
Brief Description: Review exceptions for an individual assessment from proctoring system
Level: User
Actors: Primary:Reviewer (not primary proctor)
Secondary:
Preconditions: One or more candidates have completed an assessment with proctoring tool
Triggers: Assessment session ended; routine audit requirement or incident response
Basic Flow of Events: Reviewer launches the proctoring tool in the context of the assessment in the consumer system and is presented with a list of exceptions collected by the proctoring tool for all candidates that have taken the assessment
Alternative Flows: Reviewer sees exceptions for all assessments associated with this consumer or context (course).
Use Case Title:  Schedule an Appointment
Use Case Local ID: Proctoring-10/Pre-Exam
Brief Description: Pre-register and/or schedule an appointment with a live proctor or other type of resource-limited proctoring service
Level: Sub-function
Actors: Primary:Candidate
Secondary:
Stakeholders & Interest: Stakeholder:
Interest:
Preconditions: Assessment is available with proctoring tool enabled
Triggers: Candidate made aware assessment is available and pre-registration/scheduling requirement
Basic Flow of Events: Candidate launches the proctoring tool through the consumer and is presented with registration and/or appropriate scheduling forms to complete
Notes: Optional, some services may not require any scheduling or pre-registration
Use Case Title: Schedule Blocking
Use Case Local ID: Proctoring-11
Brief Description: Request a booking from proctoring system for a given number of candidates in a given time slot.   Individual tests must still be scheduled
Level: Sub-function
Actors: Primary:Test Administrator (may be Instructor); aka Program Manager/Administrator
Secondary:
Basic Flow of Events: Consumer calls an API in the proctoring system with specification for capacity/time of desired test(s); proctoring system replies with one or more available bookings; Test Administrator selects a booking in consumer-provided user interface and booking is confirmed with proctoring system
Notes: Capacity planning for larger tests would happen out of band using the relationship between the assessment provider and the proctoring service

C. Revision History

This section is non-normative.

C.1 Version History

Spec Version No. Document Version No. Release Date Comments
IMS Candidate Final Public v1.0 1 July 2019 The first public draft release.
IMS Candidate Final Public v1.0 2 Nov 2022 Add clarifying language for extra_time parameter.

C.2 Changes in this version

Changes in this version are detailed below.

8 April 2021:

  • Revised example explanation to clarify that at the end of the assessment the Assessment Tool uses the value in the received "end_assessment_return" claim, and not the "start_assessment_return" claim.
  • Corrects miscellaneous typos and incorrect term usage.

4 March 2021:

  • Updates the document with additional language around attempt number; alters the JWT claims to use an integer value (1 instead of "1").
  • Adds new message type "LtiEndAssessment" to manage the Assessment Platform transitioning back to Proctoring Tool.

20 May 2020:

  • updates the json schema list and URLs,
  • formats the code examples for better display,
  • other minor corrections.

D. References

D.1 Normative references

[LTI-13]
1EdTech Learning Tools Interoperability (LTI)® Core Specification v1.3. C. Vervoort; N. Mills. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
[OPENID-CCORE]
OpenID Connect Core 1.0. Nat Sakimura; John Bradley; Michael B. Jones; Breno de Medeiros; Chuck Mortimore. The OpenID Foundation. URL: https://openid.net/specs/openid-connect-core-1_0.html
[OWASP-CSRF]
Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. OWASP Cheat Sheet Series. URL: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7515
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7519
[RFC7523]
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. M. Jones; B. Campbell; C. Mortimore. IETF. May 2015. Proposed Standard. URL: https://tools.ietf.org/html/rfc7523
[SEC-10]
1EdTech Security Framework v1.0. C. Smythe; C. Vervoort; M. McKell; N. Mills. 1EdTech Consortium. April 2019. 1EdTech Final Release. URL: https://www.imsglobal.org/spec/security/v1p0/

E. List of Contributors

The following individuals contributed to the development of this document:

Name Organization Role
Mallory DyerProctorio
Darrick JensenPearsonVue
Steve LayQuestionmarkEditor
Mark McKell1EdTechEditor
Mark MolenaarOAT
Mike OlsenProctorio
Shea SilvermanUCF
Colin Smythe1EdTech
Claude VervoortCengage
Diane VirgilETS
David KrainesBlackboard

1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at http://www.imsglobal.org.

Please refer to Document Name: 1EdTech Proctoring Services Specification 1.0

Date: July 2019

Specification Images: