1.1.1 Conformance Statements

All 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 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 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.

  1.1.2 Document Set

  1.2.1 Organization

An organization is a collection of people organized into a group for a common purpose or specific reason. Organizations can be part of a hierarchical structure.

  1.2.2 Role

The type of involvement a person has within an organization. In the case of a course, the typical roles are Instructor, Teaching Assistant and Learner.

  1.2.3 Membership

A relationship between a person and an organization which involves at least one role. A person cannot be a member of an organization without being assigned a role.

  1.2.4 Tool Platform and Tool

This version of the specification uses the LTI 1.3 terminology of Tool Platform and Tool, which respectively refer to Tool Consumer and Tool Provider used in the previous LTI specifications.

  2.4.1 Role query parameter

By default all the current memberships will be returned by a request to this service. However, this may be limited to only those memberships with a specified role by passing its URI in a query parameter named 'role'. For example, a query parameter of 'role=http%3A%2%2Fpurl.imsglobal.org%2Fvocab%2Flis%2Fv2%2Fmembership%23Learner' will filter the memberships to just those which have a Learner role. Since this is a context-level role, the parameter could be simplified to 'role=Learner', following the same rule which applies to the 'roles' parameter in a 'LtiResourceLinkRequest' message.

  2.4.2 Limit query parameter

The Tool may specify a maximum number of members to be returned in the response from the Platform. The Platform may use this as a guide to the number it returns but may include more or less than the value provided. If the response from a Platform does not comprise all of the members a rel="next" header link will be included to indicate how to request the next set of members. The absence of a rel="next" header link indicates that no more members are available. See [RFC8288].

Link: <https://lms.example.com/sections/2923/memberships?p=2>; rel="next"

  2.4.3 Membership differences

A response by the Names and Role Provisioning Services may include a rel="differences" header link. When present, this URL should be complete and opaque; users of this URL should not need to decorate it further (nor should further decoration be necessarily supported). When present this will specify a differences URL which the service user may use to obtain a report of all the differences in the membership between the time the differences URL was created and the time the URL is used (the current time). If a membership has been deleted during this interim period, it may be included in the response with a status of Deleted. All other entries in the response represent memberships which have been added or changed; for the latter the entry will be the state of the membership at the current time. This option is not intended to provide a history of all the changes which have taken place, merely to report any differences between the state of a membership at the current time and the state of the entire roster at the time the differences URL was created and provided in the initial service response. For example, a platform might provide this differences URL, encoding the earliest time to begin considering roster differences to report (there is no requirement for platforms to use this pattern, however). See [RFC8288].

Link: <https://lms.example.com/sections/2923/memberships?since=1422554502>; rel="differences"

  3.6.1 LTI 1.3 integration

"https://purl.imsglobal.org/spec/lti-nrps/claim/namesroleservice": {
    "context_memberships_url": "https://www.myuniv.example.com/2344/memberships",
    "service_versions": ["2.0"]
  }

  3.6.2 LTI 1.1 integration

A platform may offer this version of the service to LTI 1.1 tools.

The service endpoint is passed using the custom parameter: custom_context_memberships_v2_url.

All service requests should be secured by signing them using the lti_oauth_body_hash_ws_security Web Services Security Profile as described in the Security document [LTI-SEC-14].