2.1.1 An Abstract Representation

It is important to remember that this document contains a description of the underlying service model in terms of the abstract Application Programming Interface (API). The manner in which this abstract representation is visualized is not intended to dictate the implementation form of the Service. The breakdown of the service into its interface classes is a convenient way to document the set of behaviors. The objective for producing these interfaces is to identify and define the messages that are exchanged between the end-systems to realize the system behaviors required of the service.

The internal organization of an implementation of the full abstract API is beyond the scope of this specification. The only constraint is that the external behavior of the abstract API complies with this specification. This means that a .NET, J2EE, etc. physical implementation of this abstract API does not have to represent the functionality using the same breakdown of operations/methods. This physical implementation is not subject to the conformance specification.

It is important to note that the UML representation of the interfaces is used to help develop and document the Service Model and various Bindings. It is not a requirement for a system to implement this interface as defined i.e. to use the same parameters, etc. Conformance against this specification will be confirmed by inspecting the appropriate binding of the information model and ensuring that the relevant information is present and that different sequences of activity result in the predicted and mandated behavior. It is essential that the behaviors described by each of the operations are fully supported and that the behaviors described by different sequences are also maintained.

2.1.2 Assessment Results

A schematic representation of the structure for assessment results is shown in the Figure below.

This structure is based around an Assessment: this may be a Question and Test Interoperability (QTI) test. The assessment results structure enables the exchange of detailed scores for a simple and complex assessment. The Assessment is composed of a set of AssessmentLineItems (similar to LineItems) for which there is a set of AssessmentResults. The key differences between a LineItem and an AssessmentLineItem are:

• A LineItem MUST be aligned to a 'class' whereas an AssessmentLineItem is aligned to an assessment activity and MAY be aligned with a 'class';
• An AssessmentLineItem can reference a parent AssessmentLineItem i.e. hierarchical AssessmentLineItem structures are possible.

The management of AssessmentLineItems and AssessmentResults is achieved using a separate set of operations i.e. not using the original LineItem and Result operations.

2.2.1 Service Definition

The model for the service representation is shown in the Figure and Table below. Following the service definition are the descriptions for the set of corresponding service operations.

2.2.2 AssessmentLineItemsManagement Interface Description

This enables the management of the assessment lineItems i.e. lineitems that are used to store results about tests/assessments and where these test/assessments are not aligned to a class.

The set of operations for this interface are summarized in the Table below.

2.2.3 AssessmentResultsManagement Interface Description

This enables the management of the assessment results i.e. results that are used to store scores for tests/assessments and where these test/assessments are not aligned to a class.

The set of operations for this interface are summarized in the Table below.

2.3.1 AssessmentLineItemSet Class Description

The data model for the "AssessmentLineItemSet" class is shown in the Figure and the accompanying definition in the Table below.

2.3.2 AssessmentResultSet Class Description

The data model for the "AssessmentResultSet" class is shown in the Figure and the accompanying definition in the Table below.

2.3.3 GUID Class Description

The data model for the "GUID" class is shown in the Figure below and the accompanying definition in the below.

2.3.4 SingleAssessmentLineItem Class Description

The data model for the "SingleAssessmentLineItem" class is shown in the Figure below and the accompanying definition in the Table below.

2.3.5 SingleAssessmentResult Class Description

The data model for the "SingleAssessmentResult" class is shown in the Figure below and the accompanying definition in the Table below.

2.3.6 imsx_StatusInfo Class Description

The data model for the "imsx_StatusInfo" class is shown in the Figure and the accompanying definition in the Table below.

3.1.1 Mapping of the Service Operations to the REST Endpoints

The mapping between the service operations and the REST Endpoint URL-leaf values are listed in the Table below. The syntax and semantics for this mapping are described in [ORGBK-JSON-12].

3.1.2 API Root URL and Versioning

All of the paths MUST also contain, as the base of the path, excluding the host name, the string: "/ims/oneroster/gradebook/v1p2".

3.1.3 Predefined Endpoint Query Parameters

The definition of the permitted set of query parameters are defined in the following Tables. The syntax and semantics for this Tables are described in [ORGBK-JSON-12].

3.1.4 HTTP Code Handling

A service provider will either return a data payload or a payload that indicates the cause of the failure. The list of HTTP Codes and handling for each endpoint is shown in the Table below. The syntax and semantics for this tabular description are described in [ORGBK-JSON-12].

3.1.5 Service Discovery

A Service Provider MUST provide a localized version of the OpenAPI file (version 3 JSON file format) to enable service discovery [Security]

This file MUST be located at: "...hostname.../ims/oneroster/gradebook/v1p2/discovery/".

The OpenAPI file MUST have the name: "assessmentresultv1p0service_openapi3_v1p0".

Therefore the full URL for this service discovery file is: "...hostname.../ims/oneroster/gradebook/v1p2/discovery/assessmentresultv1p0service_openapi3_v1p0.json".

3.2.1 Pagination

For requests of collections i.e. the response for the 'getAllAssessmentLineItems()', etc. call, there is a danger of data overload. To avoid this, implementations should adopt a pagination mechanism. Pagination is controlled via two parameters that are appended to the request:

• 'limit' - the number of results to return (the default value is 100);
• 'offset' - the index of the first record to return (zero index and so the default value is 0).

An example of a request to return the first 10 resources in a collection of lineItems:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/lineItems?limit=10

An example of a request to return the second 10 resources in a collection of lineItems:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/lineItems?limit=10&offset=10

It is RECOMMENDED that implementations pass the total resource count in collection back to the requester. This MUST be provided in the custom HTTP header: X-Total-Count.

It is RECOMMENDED that implementers pass back next, previous, first and last links in the HTTP Link Header.

Consider the requests for the example where 503 resources exist in the collection. The pagination is in units of 10.

    Link:

    <https://imsglobal.org/ims/oneroster/gradebook/v1p2/assessmentLineItems?limit=10&offset=20>; rel="next",

    <https://imsglobal.org/ims/oneroster/gradebook/v1p2/assessmentLineItems?limit=3&offset=500>; rel="last",

    <https://imsglobal.org/ims/oneroster/gradebook/v1p2/assessmentLineItems?limit=10&offset=0>; rel="first",

    <https://imsglobal.org/ims/oneroster/gradebook/v1p2/assessmentLineItems?limit=10&offset=0>; rel="prev"

3.2.2 Sorting

It should be possible for collections, i.e. the response for the 'getAllAssessmentResults()', etc. calls, to be returned in a sorted order. It should be possible to sort the collection based on any single data element in the core description of the resource. Sort requests MUST make use of the reserved word "sort" (?sort= data_field), and optionally the reserved word orderBy for which:

• 'data_field' MUST be used in the request to ask for the collection to be sorted on data field. The form of ordering is implementation dependent if the 'orderBy' attribute is not used;
• 'orderBy' MAY be used in the request to ask for the collection to be ordered ascending (asc) or descending (desc).

An example of a request to ask for a list of students sorted into ascending familyName order:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/results?sort=score&orderBy=asc

Sorting should conform to the use of the Unicode Collation Algorithm [UNICODE] when using the relevant comparisons.

If the consumer requests that the data is to be sorted by a non-existent field, data MAY be returned in the service provider's default sort order or an error response MAY be returned.

When sorting/ordering is requested on a property that is an array, the first value in the array is used as the basis of the sorting/ordering.

To sort/order on the properties of nested objects, (for example, with metadata properties), a dot-notation approach MUST be used. The format for this is:

    ?sort=<Nested_Object>.<Property>

3.2.3 Filtering

For the calls that request collections e.g. 'getAllLineItems()', etc. call, it should be possible to filter collections for elements matching a certain criteria. It should be possible to filter collections based on any data element in the core description of the resource.Filter requests MUST take the form:

    ?filter=<data_field><predicate><value>

or

    ?filter=<data_field><predicate><value><logical><data_field><predicate><value>

The data fields that can be used are those present in the class definition being filtered. So for example in 'results', it MUST be possible to filter on: 'sourcedId', 'score, 'dateLastModified', etc.

Predicates MUST be chosen from those listed in the Table below:

Values MUST be enclosed within single quotes and they MUST be handled as case insensitive. When the response is returned it is the receiving system that should consider whether or not case-sensitivity is important.

The <logical> parameters allow more complex queries to be created. For version 1.0, it is RECOMMENDED that logical operations are limited to " AND " and " OR " (note the surrounding white space at each side) and that there is only one such operator used in any filter i.e. a single 'AND' or a single 'OR' in the filter. A single white space must occur before and after the parameter.

To query on the properties of nested objects, (for example, with metadata properties), a dot-notation approach MUST be used. The format for this is:

    ?filter=<Nested_Object>.<Property>

Note then when querying on metadata, the property is loosely typed. An example or a request to find 'lineItems' with a 'dueDate' of '2017-01-01T00:00:00Z' is:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/lineItems?filter=dueDate='2017-01-01T00:00:00Z'

URL encoded as:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/lineItems?filter=role%3D%272017-01-01T00:00:00Z%27

Filter queries MUST be URL encoded.

An example of a complex query for all 'lineItems' with a dueDate='2017-01-01T00:00:00Z' AND dateLastModified>'2016-12-12T00:00:00Z' is:

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/lineItems?filter=dueDate%3D%272017%3D01%3D01T00%3A00%3A00Z%27%20AND%20dateLastModified%3E%272016%3D12%3D12T00%3A00%3A00Z%27

When filtering on objects that are arrays the application of the filter depends on the nature of the comparison. So in the case of filtering on the 'subject' (this is not a field in 'lineItem' but is used as a generic example of filters for arrays) field when the value of the field is "subject1,subject2,subject3" the following filters would return:

• ?filter=subject='subject1' - record not returned;
• ?filter=subject='subject1,subject2' - record not returned;
• ?filter=subject='subject1,subject2,subject3' - record returned;
• ?filter=subject~'subject1' - record returned;
• ?filter=subject~'subject1,subject2' - record returned;
• ?filter=subject~'subject1,subject2,subject3' - record returned.

This means filtering using the '=' has 'AND' semantics and for '~' has 'OR' semantics. Filtering rules should conform to the use of the Unicode Collation Algorithm [UNICODE, 16] when using the relevant comparisons.

If the consumer requests that data be filtered by a non-existent field, NO data is returned and the server must provide the associated transaction status code information of:

• CodeMajor value is 'failure';
• Severity value is 'error';
• CodeMinor value is 'invalid_filter_field'.

3.2.4 Field Selection

For the read collection calls, such as 'getAllAssessmentResults()', etc. it should be possible for requesters to select the range of fields to be returned. By default, all mandatory and optional fields from the core description of the resource MUST be returned. If any fields are specified in the request then the implementation should return those fields AND ONLY those fields i.e. the multiplicity rules for an element are overridden. Any field or fields from the Data Model MAY be requested.

Field selection request MUST make use of the reserved word 'fields'. The value of fields is a comma delimited list of the fields to return. An example of a request message to ask for a list of Results returning only the 'sourcedId' and 'score':

    GET https://imsglobal.org/ims/oneroster/gradebook/v1p2/assessmentResults?fields=sourcedId,score

If the consumer requests that data be selected using non-existent field, ALL data for the record is returned. If the consumer requests that data be selected using a blank field the request will be treated as an invalid request. The server must provide the associated transaction status code information of:

• CodeMajor value is 'failure';
• Severity value is 'error';
• CodeMinor value is 'invalid_selection_field'.

3.3.1 Transport Security

As the service will be exposing personal data related to students and their grades, it is important that only authorized users have access to that data. Further, data exchanges should be encrypted to ensure that packet sniffing cannot be used to read the data in transit.

All Requests and Responses MUST be sent using Transport Layer Security (TLS). Exchange of the signed certificates for endpoints between clients and servers is beyond the scope of this specification. Implementers of clients and servers are advised to look at the various 3rd party certificate signing services in order to obtain signed certificates.

Support for TLS 1.2 and/or TLS 1.3 is REQUIRED and SSL MUST NOT be used.

3.3.2 Authorization

The use of OAuth 2.0 Client Credentials with the Bearer Token obtained using the mechanism described in [RFC6749] (Section 4.4) is REQUIRED. Details of this are given in the IMS Security Framework [Security].

Authorization will use the OAuth 2.0 Client Credentials Grant mechanism. In this mechanism the client can request an access token using only its client credentials (using the consumer key and secret information) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server. In this approach the client issues a client authentication request and receives in response an access token. Issuing of an access token is defined in Section 5 of [RFC6749].

The request for an access token, including three scopes (scopename1, scopename2 and scopenamex) takes the form of (this uses TLS):

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=scopename1%20scopename2%20scopenamex

The inclusion of scopes is REQUIRED and the set of scopes available for this service are defined in the following subsection. The authorization encoding is produced using the consumer key and secret. Success results in the granting of the access token with a response of:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token" : "2YotnFZFEjr1zCsicMWpAA",
    "token_type" : "bearer",
    "expires_in" : 3600,
    "scope" : "scopename1 scopename2 scopenamex"
}

The recommended default value for the "expires_in" is 3600s. The authorization server MUST provide the scopes which are made available (either all or a subset of the scopes supplied in the request).

The client utilizes the access token to authenticate with the resource using the HTTP "Authorization" request header field [RFC2617] with an authentication scheme defined by the specification of the access token type used, such as [RFC6750]. An example of the use of the bearer token is:

GET /resource/1 HTTP/1.1
Host: provider.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

NOTE: This exchange assumes that TLS is used to secure the link.

3.3.3 Scopes

The set of scopes available in this service are listed in the following Tables.

3.4.1 "deleteAssessmentLineItem" Request Payload

There is no payload for this request.

3.4.2 "deleteAssessmentLineItem" Response Payloads

{
    "imsx_codeMajor" : "success"|"processing"|"failure"|"unsupported",
    "imsx_severity" : "status"|"warning"|"error",
    "imsx_description" : "..String..",
    "imsx_CodeMinor" : {
        "imsx_codeMinorField" : [
            {
                "imsx_codeMinorFieldName" : "..NormalizedString..",
                "imsx_codeMinorFieldValue" : "fullsuccess"|"invalid_filter_field"|"invalid_selection_field"|"invaliddata"|
                				"unauthorisedrequest"|"internal_server_error"|"server_busy"|"deletefailure"|
                				"unknownobject"|"forbidden"
            },
            {...},
            {...}
        ]
    }
}

3.4.3 "deleteAssessmentResult" Request Payload

There is no payload for this request.

3.4.4 "deleteAssessmentResult" Response Payloads

{
    "imsx_codeMajor" : "success"|"processing"|"failure"|"unsupported",
    "imsx_severity" : "status"|"warning"|"error",
    "imsx_description" : "..String..",
    "imsx_CodeMinor" : {
        "imsx_codeMinorField" : [
            {
                "imsx_codeMinorFieldName" : "..NormalizedString..",
                "imsx_codeMinorFieldValue" : "fullsuccess"|"invalid_filter_field"|"invalid_selection_field"|"invaliddata"|
                				"unauthorisedrequest"|"internal_server_error"|"server_busy"|"deletefailure"|
                				"unknownobject"|"forbidden"
            },
            {...},
            {...}
        ]
    }
}

3.4.5 "getAllAssessmentLineItems" Request Payload

There is no payload for this request.

3.4.6 "getAllAssessmentLineItems" Response Payloads

{
    "assessmentLineItems" : [
        {
            "sourcedId" : "..String..",
            "status" : "active"|"tobedeleted",
            "dateLastModified" : "..Date/Time..",
            "metadata" : {
                "..permitted extension point.." : "..user defined value.."
            },
            "title" : "..NormalizedString..",
            "description" : "..String..",
            "class" : {
                "href" : "..URI..",
                "sourcedId" : "..String..",
                "type" : "class"
            },
            "parentAssessmentLineItem" : {
                "href" : "..URI..",
                "sourcedId" : "..String..",
                "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
                		"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
            },
            "scoreScale" : {
                "href" : "..URI..",
                "sourcedId" : "..String..",
                "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
                		"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
            },
            "resultValueMin" : ..Number(Float)..,
            "resultValueMax" : ..Number(Float)..,
            "learningObjectiveSet" : [
                {
                    "source" : "..select from Union..",
                    "learningObjectiveIds" : [ "..NormalizedString..", ..., "..NormalizedString.." ]
                },
                {...},
                {...}
            ]
        },
        {...},
        {...}
    ]
}

{
    "imsx_codeMajor" : "success"|"processing"|"failure"|"unsupported",
    "imsx_severity" : "status"|"warning"|"error",
    "imsx_description" : "..String..",
    "imsx_CodeMinor" : {
        "imsx_codeMinorField" : [
            {
                "imsx_codeMinorFieldName" : "..NormalizedString..",
                "imsx_codeMinorFieldValue" : "fullsuccess"|"invalid_filter_field"|"invalid_selection_field"|"invaliddata"|
                	"unauthorisedrequest"|"internal_server_error"|"server_busy"|"deletefailure"|"unknownobject"|"forbidden"
            },
            {...},
            {...}
        ]
    }
}

3.4.7 "getAllAssessmentResults" Request Payload

There is no payload for this request.

3.4.8 "getAssessmentLineItem" Request Payload

There is no payload for this request.

3.4.9 "getAssessmentResult" Request Payload

There is no payload for this request.

3.4.10 "putAssessmentLineItem" Request Payload

A tabular description of the request payload is shown in the Table below.

An example of the request payload is shown in the code block below.

{
    "assessmentLineItem" : {
        "sourcedId" : "..String..",
        "status" : "active"|"tobedeleted",
        "dateLastModified" : "..Date/Time..",
        "metadata" : {
            "..permitted extension point.." : "..user defined value.."
        },
        "title" : "..NormalizedString..",
        "description" : "..String..",
        "class" : {
                "href" : "..URI..",
                "sourcedId" : "..String..",
                "type" : "class"
        },
        "parentAssessmentLineItem" : {
            "href" : "..URI..",
            "sourcedId" : "..String..",
            "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
            	"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
        },
        "scoreScale" : {
            "href" : "..URI..",
            "sourcedId" : "..String..",
            "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
            	"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
        },
        "resultValueMin" : ..Number(Float)..,
        "resultValueMax" : ..Number(Float)..,
        "learningObjectiveSet" : [
            {
                "source" : "..select from Union..",
                "learningObjectiveIds" : [ "..NormalizedString..", ..., "..NormalizedString.." ]
            },
            {...},
            {...}
        ]
    }
}

3.4.11 "putAssessmentLineItem" Response Payloads

{
    "imsx_codeMajor" : "success"|"processing"|"failure"|"unsupported",
    "imsx_severity" : "status"|"warning"|"error",
    "imsx_description" : "..String..",
    "imsx_CodeMinor" : {
        "imsx_codeMinorField" : [
            {
                "imsx_codeMinorFieldName" : "..NormalizedString..",
                "imsx_codeMinorFieldValue" : "fullsuccess"|"invalid_filter_field"|"invalid_selection_field"|"invaliddata"|
                	"unauthorisedrequest"|"internal_server_error"|"server_busy"|"deletefailure"|"unknownobject"|"forbidden"
            },
            {...},
            {...}
        ]
    }
}

3.4.12 "putAssessmentResult" Request Payload

A tabular description of the request payload is shown in the Table below.

An example of the request payload is shown in the code block below.

{
    "assessmentResult" : {
        "sourcedId" : "..String..",
        "status" : "active"|"tobedeleted",
        "dateLastModified" : "..Date/Time..",
        "metadata" : {
            "..permitted extension point.." : "..user defined value.."
        },
        "assessmentLineItem" : {
            "href" : "..URI..",
            "sourcedId" : "..String..",
            "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
            	"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
        },
        "student" : {
            "href" : "..URI..",
            "sourcedId" : "..String..",
            "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
            	"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
        },
        "score" : ..Number(Float)..,
        "textScore" : "..NormalizedString..",
        "scoreDate" : "..String(Date)..",
        "scoreScale" : {
            "href" : "..URI..",
            "sourcedId" : "..String..",
            "type" : "academicSession"|"category"|"class"|"course"|"demographics"|"enrollment"|"lineItem"|"org"|
            	"resource"|"result"|"student"|"teacher"|"user"|"term"|"gradingPeriod"|"scoreScale"|"school"
        },
        "scorePercentile" : ..Number(Float)..,
        "scoreStatus" : "exempt"|"fully graded"|"not submitted"|"partially graded"|"submitted"|"late"|
        	"incomplete"|"missing"|"withdrawal"|"in progress",
        "comment" : "..String..",
        "learningObjectiveSet" : [
                {
                    "source" : "..select from Union..",
                    "learningObjectiveResults" : [
                        {
                            "learningObjectiveId" : "..NormalizedString..",
                            "score" : ..Number(Float)..,
                            "textScore" : "..NormalizedString.."
                        },
                        {...},
                        {...}
                    ]
                },
                {...},
                {...}
        ],
        "inProgress" : "true"|"false",
        "incomplete" : "true"|"false",
        "late" : "true"|"false",
        "missing" : "true"|"false"
    }
}

3.5.1 Extending the Binding

Proprietary extensions of the service are based upon two approaches:

• The extension of the data models being manipulated by the current set of operations;
• The inclusion of new operations to support new proprietary functionality.

It is NOT permitted to change the behavior of the current set of operations. Such changes MUST be supported by the creation of new operations.

3.5.2 Profiling the Binding

This Service can be profiled. In general, Profiling is used to:

• Refine which Interfaces are used and which operations are supported for each Interface;
• Refine the data models by increasing the constraints on the base definitions.

Valid Profiles must be restrictive i.e. optional features can be removed or constraints increased but new features must not be added. A Profile of this service is made by annotating the UML supplied with the documentation for the specification.

It is strongly recommended that a profile of this specification is undertaken either by, or with the close support, of IMS Global. However, no matter who is responsible for creating the profile artefacts (documents, OpenAPI files, XSDs, etc.), it is strongly recommended that the IMS specification tools are used. This will ensure that the artefacts are consistent with the base specifications and that useful support documentation is automatically produced e.g. creation of a document that summarises the differences between the base specification and the profile. Organizations wishing to produce a profile of this specification should contact Lisa Mattson (IMS Global Chief Operations Officer) at: lmattson@imsglobal.org.

5.1.1 Requirements for Assessment Result Management Profile v1.0 Conformance

All tests must be passed successfully to be considered 1EdTech Assessment Result Management Profile compliant.

5.1.2 Conformance Mark

After you have submitted your successful conformance information to conformance@imsglobal.org, and received confirmation and a registration number from 1EdTech you may then apply the appropriate conformance mark. The 1EdTech conformance chart will list your conformance details. If you have any questions, please feel free to contact us at any point.

Membership in the OneRoster/Learning Information Services Alliance is the only way to achieve official conformance to the Assessment Result Management Profile standard. Products without a 1EdTech conformance Registration Number are not considered to be compliant by 1EdTech.

5.4.1 Service Provider Certification

The functional capabilities of such systems are:

• They MUST support the assessment results management profile set of endpoints;
• All of either the pull or the push modes required endpoints MUST be supported;
• Any of the optional endpoints MAY be supported (from both the pull and push modes);
• They MUST supply all of the required data fields;
• They MAY supply any of the optional data fields;
• They MAY provide extension data fields;
• They MUST support the endpoint payload pagination mechanism for all responses that provide a collection in the payload;
• They MUST support the endpoint payload filtering mechanism for all responses that provide a collection in the payload;
• They MUST support the endpoint payload sorting mechanism for all responses that provide a collection in the payload;
• They MUST support the endpoint payload field selection mechanism for all responses that provide a collection or a singleton in the payload;
• They MUST support the OAuth 2.0 Bearer Token authentication mechanism;
• The OpenAPI file that describes the functionality of the available ARP-GS services MUST be published at the endpoint base URL. This MUST be a valid OpenAPI 3.0 JSON file at the URL: "...hostname..."/ims/oneroster/gradebook/v1p2/discovery/assessmentresultv1p0service_openapi3_v1p0.json.

Systems that wish to undertake conformance testing as a Service Provider should use the conformance test system located at: https://???tbd..

5.4.2 Service Consumer Certification

The functional capabilities of such systems are:

• They MUST support the assessment results management profile set of endpoints;
• All of either the pull or the push modes required endpoints MUST be supported;
• Any of the optional endpoints MAY be supported (from both the pull and push modes);
• They MUST support all of the required data fields;
• They MAY support any of the optional data fields;
• They MAY process extension data fields;
• They MUST support the endpoint payload pagination mechanism for all requests that provide a collection in the response payload;
• They MUST support the endpoint payload filtering mechanism for all requests that provide a collection in the response payload;
• They MUST support the endpoint payload sorting mechanism for all requests that provide a collection in the response payload;
• They MUST support the endpoint payload field selection mechanism for all requests that provide a collection or a singleton in the response payload;
• They MUST support the OAuth 2.0 Bearer Token authentication mechanism.

Systems that wish to undertake conformance testing as a Service Consumer should use the conformance test system located at: >https://???tbd..

5.4.3 Comparison of the Certifications

A comparison of the available certifications for the defined OneRoster endpoints is shown in the Table below. The key for this Table is:

• 'C' denotes a service consumer;
• 'P' denotes a service provider;
• 'Init' denotes that the end-system issues the request (a shaded box denotes that support for the endpoint is required for that mode);
• 'Resp' denotes that the end-system responds to the request (a shaded box denotes that support for the endpoint is required for that mode)-
• '-' denotes that the endpoint is not available to that operational mode.