notice_type. (REQUIRED) Must be one of the LTI platform notice types supported by the Platform within the service's deployment.

handler. (REQUIRED) Must be a valid URL using the HTTPS scheme; the domain for the handler must be the same as the Tool's full domain (as specified in at least one of the Redirect URLs and/or domain property for the Tool's registration).

max_batch_size. (OPTIONAL) If present, must be a JSON number greater than 0; the tool uses this to signal its desired maximum batch size. To accept the subscription size, the Platform must be able to send notices in batches up to (but not more than) this size; if the Platform cannot accept this limit, it should reject the subscription request and send back an error result. Note that the batch size gets specified (and may vary) for every distinct notice type.

Tools should consider that Platforms which support batching may well insist upon a reasonable minimum batch size (for example, ten notices per batch).

If not specified by the Tool, the Platform may freely decide on batch size for sending notices.

If this request is successful, the Platform should respond with a single JSON object describing the successfully registered subscription, as in the following example:

{ 
   "notice_type": "LtiContextCopyNotice",
   "handler": "https://www.myltitool.com/deployments/97f1ca3b-3093-49a9-af60-4db23aa4b979/dataPrivacyNotices/"
}

If this request is not successful, the Platform should use these status code responses:

400. If the Tool attempts to register a handler for a notice type the Platform does not offer, a handler with an invalid domain, a handler with an unsatisfactorily low requested maximum batch-size, or some other "bad data" in the registration payload.

403. If the Tool has no permission to read or register a new notice type.

Other status code responses may be appropriate for other specific error states.

When a Tool registers a notice handler it expects that registration to be durable (to exist until it, itself, decides to remove it via use of the service). The Platform SHOULD respect this and make best effort to not unilaterally make changes to a registered handler once it has been accepted via use of the service.

In particular, this means that the Platform MUST distinguish between workflows where a Tool's access to the service might be "disabled" for some reason, and those where a Tool's access to the service might be "deleted". In the former case, there is a possibility for recovery or re-enablement; in the latter, there is no expectation of that. After a Tool has successfully registered a notice handler, the Platform MUST remember that registration and retain it (restore it or re-enable it) across situations where the Tool's access to the service might be "disabled".

The envelope for notices has the following properties:

notices (REQUIRED). List of one or more platform notice objects. See the following section for further description of these objects.

{
   "notices": [
      { "jwt": " ... " },
      { "jwt": " ... " }, ...
   ]
}

Each notice object in the envelope's list has the following properties:

jwt (REQUIRED). The platform notice JWT itself. See the following section for a description of its constituent elements.

Each notice in the envelope's list must be of the same notice type (even if the Tool's notice handler endpoint is the same across multiple notice types).

{
   "notices": [
       { 
        "jwt": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3BsYXRmb3JtLmV4YW1wbGUub3JnLyIsImF1ZCI6WyI5NjJmYTRkOC1iY2JmLTQ5YTAtOTRiMi0yZGUwNWFkMjc0YWYiXSwiZXhwIjoxNTEwMTg1NzI4LCJpYXQiOjE1MTAxODUyMjgsIm5vbmNlIjoiN2ZlNTQ1YmItNDU5My00YTZhLThlZjMtZTFiYWEyYTBjNjk1IiwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vbm90aWNlIjp7ImlkIjoiNjI0ODY2NGQtMDZiMi00Njg0LTllZmItN2E4YzcyZWEwZWZmIiwidGltZXN0YW1wIjoiMjAyNC0wNS0yMVQxNjoxNDo0Ni4zMTErMDA6MDAiLCJ0eXBlIjoiTHRpQ29udGV4dENvcHlOb3RpY2UifSwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vdmVyc2lvbiI6IjEuMy4wIiwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vZGVwbG95bWVudF9pZCI6IjA3OTQwNTgwLWIzMDktNDE1ZS1hMzdjLTkxNGQzODdjMTE1MCIsImh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvbHRpL2NsYWltL3Rvb2xfcGxhdGZvcm0iOnsiZ3VpZCI6IjQ4YmJiNTQxLWNlNTUtNDU2ZS04YjdkLWViYzU5YTM4ZDQzNSJ9LCJodHRwczovL3B1cmwuaW1zZ2xvYmFsLm9yZy9zcGVjL2x0aS9jbGFpbS9jb250ZXh0Ijp7ImlkIjoiYzFkODg3ZjAtYTFhMy00YmNhLWFlMjUtYzM3NWVkY2MxMzFhIiwibGFiZWwiOiJDUFMgNDM1YSIsInRpdGxlIjoiQ1BTIDQzNSBMZWFybmluZyBBbmFseXRpY3MgQSIsInR5cGUiOlsiaHR0cDovL3B1cmwuaW1zZ2xvYmFsLm9yZy92b2NhYi9saXMvdjIvY291cnNlI0NvdXJzZU9mZmVyaW5nIl19LCJodHRwczovL3B1cmwuaW1zZ2xvYmFsLm9yZy9zcGVjL2x0aS9jbGFpbS9vcmlnaW5fY29udGV4dHMiOlsiZmI5ZmNjZjktNjMyMS00ZGEwLTk5ZDEtODg0YWNlOTMyYzA4IiwiYmFmMjJkNDYtMGRkZi00NTk5LTlmNmMtMWQ5MzNlMzY0OTBlIl19.OZAqzud-cT9aCxv56tKrE38u-H8jxR_Pyclbwqu5EZYvI7x6D4CpP4mvhXDLwB9N1zgOPGDHNmYEp9oFsCHPAsgbeQtTtwVuBlHzqpv3DbBQ66neNPHkm9f124Ql6fZq20spFJyToN3L--lH6k6trWtFVxS_zFngV_qFyz5qxAwLX5xnTT4RRYd6ZJ-YlT0NOvXJPlm_1fBPtBROS078owldXZ1ctp7NsUNIt0eF-ghTTvnQ_gTcfdo2IhcR2wgWwfqZR50JytuKHHhPBnx_M9XMIxCXRAqpMeT97bjWaO5e0LJqQBTf3Yylfd6u3BxEJ0kXMN9YROlkHk6cPTPKCQ"
       },
       { 
        "jwt": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3BsYXRmb3JtLmV4YW1wbGUub3JnLyIsImF1ZCI6WyI5NjJmYTRkOC1iY2JmLTQ5YTAtOTRiMi0yZGUwNWFkMjc0YWYiXSwiZXhwIjoxNTEwMTg1NzI4LCJpYXQiOjE1MTAxODUyMjgsIm5vbmNlIjoiN2ZlNTQ1YmItNDU5My00YTZhLThlZjMtZTFiYWEyYTBjNjk1IiwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vbm90aWNlIjp7ImlkIjoiNjI0ODY2NGQtMDZiMi00Njg0LTllZmItN2E4YzcyZWEwZWZmIiwidGltZXN0YW1wIjoiMjAyNC0wNS0yMVQxNjoxNDo0Ni4zMTErMDA6MDAiLCJ0eXBlIjoiTHRpQ29udGV4dENvcHlOb3RpY2UifSwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vdmVyc2lvbiI6IjEuMy4wIiwiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5vcmcvc3BlYy9sdGkvY2xhaW0vZGVwbG95bWVudF9pZCI6IjA3OTQwNTgwLWIzMDktNDE1ZS1hMzdjLTkxNGQzODdjMTE1MCIsImh0dHBzOi8vcHVybC5pbXNnbG9iYWwub3JnL3NwZWMvbHRpL2NsYWltL3Rvb2xfcGxhdGZvcm0iOnsiZ3VpZCI6IjQ4YmJiNTQxLWNlNTUtNDU2ZS04YjdkLWViYzU5YTM4ZDQzNSJ9LCJodHRwczovL3B1cmwuaW1zZ2xvYmFsLm9yZy9zcGVjL2x0aS9jbGFpbS9jb250ZXh0Ijp7ImlkIjoiYzFkODg3ZjAtYTFhMy00YmNhLWFlMjUtYzM3NWVkY2MxMzFhIiwibGFiZWwiOiJDUFMgNDM1YSIsInRpdGxlIjoiQ1BTIDQzNSBMZWFybmluZyBBbmFseXRpY3MgQSIsInR5cGUiOlsiaHR0cDovL3B1cmwuaW1zZ2xvYmFsLm9yZy92b2NhYi9saXMvdjIvY291cnNlI0NvdXJzZU9mZmVyaW5nIl19LCJodHRwczovL3B1cmwuaW1zZ2xvYmFsLm9yZy9zcGVjL2x0aS9jbGFpbS9vcmlnaW5fY29udGV4dHMiOlsiZmI5ZmNjZjktNjMyMS00ZGEwLTk5ZDEtODg0YWNlOTMyYzA4IiwiYmFmMjJkNDYtMGRkZi00NTk5LTlmNmMtMWQ5MzNlMzY0OTBlIl19.OZAqzud-cT9aCxv56tKrE38u-H8jxR_Pyclbwqu5EZYvI7x6D4CpP4mvhXDLwB9N1zgOPGDHNmYEp9oFsCHPAsgbeQtTtwVuBlHzqpv3DbBQ66neNPHkm9f124Ql6fZq20spFJyToN3L--lH6k6trWtFVxS_zFngV_qFyz5qxAwLX5xnTT4RRYd6ZJ-YlT0NOvXJPlm_1fBPtBROS078owldXZ1ctp7NsUNIt0eF-ghTTvnQ_gTcfdo2IhcR2wgWwfqZR50JytuKHHhPBnx_M9XMIxCXRAqpMeT97bjWaO5e0LJqQBTf3Yylfd6u3BxEJ0kXMN9YROlkHk6cPTPKCQ"
       }
   ]
}

All LTI platform notices also use the following fundamental LTI-specific claims; each claim name is prefaced with https://purl.imsglobal.org/spec/lti/claim/ (for brevity, the descriptions below contain only the portion of the URL path following the preface):

notice (REQUIRED). This claim's value is an object containing all the notice-specific properties for the conveying notice. See following section for further description.

version (REQUIRED). This claim's value contains a string that indicates the version of LTI to which the notice conforms.

deployment_id (REQUIRED). This claim's value contains a case-sensitive string that identifies the Platform-Tool integration governing the notice. It has the same restrictions as described in the LTI 1.3 Core specification [LTI-13].

context (OPTIONAL). In some cases, a platform notice may concern a single LTI Context as the boundary of the notice. In these cases, this claim holds the same value and restrictions as described in the LTI 1.3 Core specification [LTI-13].

custom (OPTIONAL). The custom claim acts like a key-value map of defined custom properties that a platform may associate with the current context and any notices or messages sent from the context. This claim holds the same value and restrictions as described in the LTI 1.3 Core specification [LTI-13].

tool_platform (OPTIONAL). In some cases, a platform notice may wish to indicate details about the sending Platform. In these cases, this claim holds the same value and restrictions as described in the LTI 1.3 Core specification [LTI-13].

The https://purl.imsglobal.org/spec/lti/claim/notice claim contains all the notice-specific properties for the conveying notice.

id (REQUIRED). This property value contains a persistent identifier for the notice itself. The identifier MUST be persistently unique within the scope of the LTI deployment (that is, once used, it must never be re-used).

timestamp (REQUIRED). This property value contains a date and time for the event occurrence within the platform that prompted the notice (rather than, for example, the time when this notice's JWT was formed). The property value MUST include a time zone designator (Z designator or +00:00 offset to specify UTC, or time offset from UTC for another time zone).

type (REQUIRED). This property value contains a string that indicates the type of the sender's LTI platform notice.

Vendors MAY extend the information model for any notice type and inject additional claims into the notice's JSON body by adding one or more claims. Rules for adding such claims are as described in the LTI 1.3 Core specification [LTI-13].

LTI platform notices specified in other documents may supplement the fundamental claims described previously with additional claims specific to the needs of the platform notice type.

LTI platform notices specified in other documents may make required any optional fundamental notice claim defined here.

As in the core LTI specification, platforms can optionally indicate relevant services to tools by including additional claims (service descriptor claims) in notices. Each service, when described, must have a seprate claim to contain the endpoints (and possibly other properties) relevant for that service. The endpoints and properties the platform sends for a service may vary from notice to notice and are always fully resolved.

The platform SHOULD include service descriptors for relevant services in notices that are the first indication a tool may have about that context (for example in notices that signal the creation of a new Deployment or Context). This allows the tool to immediately use services to bootstrap configuration and set up, without having to wait for a message from a user launch.