Apply bold styling and uppercase MI21 statements

Addresses:
- #472 (comment)
- #472 (comment)

slate/source/includes/_scopes.md.erb

@@ -42,7 +42,7 @@ Scope Name | Scope ID |Description
 
 ## Admin & Registration
 
-The following scopes are used for administrative interactions. These scopes MUST never be included in the same access token as a CDR Data scope.
+The following scopes are used for administrative interactions. These scopes **MUST** never be included in the same access token as a CDR Data scope.
 
 
 Scope Name | Scope ID |Description

slate/source/includes/additional/candidates/dp306/_product_components-dp306.md

@@ -77,10 +77,10 @@ Description of the usage of the _eligibilityType_ field as it applies to product
 | MIN_TURNOVER | Only a business with greater than a minimum turnover may apply. | Minimum turnover in [AmountString](#common-field-types) format. |
 | NATURAL_PERSON | The customer must be a natural person rather than another legal entity. | N/A |
 | OTHER | Another eligibility criteria exists as described in the _additionalInfo_ field (if this option is specified then the _additionalInfo_ field is mandatory). | N/A |
-| PENSION_RECIPIENT | Only a recipient of a government pension may apply for the product. | Optional. If present, MUST contain a description of which pensions qualify. |
+| PENSION_RECIPIENT | Only a recipient of a government pension may apply for the product. | Optional. If present, **MUST** contain a description of which pensions qualify. |
 | RESIDENCY_STATUS | An eligibility constraint based on residency status applies. | A description of the status required. |
 | STAFF | Only a staff member of the provider may apply. | N/A |
-| STUDENT | Only students may apply for the product. | Optional. If present, MUST contain a description of who qualifies as a student, e.g., do apprentices qualify? |
+| STUDENT | Only students may apply for the product. | Optional. If present, **MUST** contain a description of who qualifies as a student, e.g., do apprentices qualify? |
 
 
 
@@ -169,10 +169,10 @@ Description of the usage of the _discountEligibilityType_ field as it applies to
 | MIN_TURNOVER | Only a business with greater than a minimum turnover is eligible. | Minimum turnover in [AmountString](#common-field-types) format. |
 | NATURAL_PERSON | The customer must be a natural person rather than another legal entity. | N/A |
 | OTHER | Another eligibility criteria exists as described in the _additionalInfo_ field (if this option is specified then the _additionalInfo_ field is mandatory). | N/A |
-| PENSION_RECIPIENT | Only a recipient of a government pension may receive the discount. | Optional. If present, MUST contain a description of which pensions qualify. |
+| PENSION_RECIPIENT | Only a recipient of a government pension may receive the discount. | Optional. If present, **MUST** contain a description of which pensions qualify. |
 | RESIDENCY_STATUS | An eligibility constraint based on residency status applies. | A description of the status required. |
 | STAFF | Only a staff member of the provider may receive the discount. | N/A |
-| STUDENT | Only students may receive the discount. | Optional. If present, MUST contain a description of who qualifies as a student, e.g., do apprentices qualify? |
+| STUDENT | Only students may receive the discount. | Optional. If present, **MUST** contain a description of who qualifies as a student, e.g., do apprentices qualify? |
 
 
 

slate/source/includes/secondary/_energy_apis.md

@@ -10,7 +10,7 @@ AEMO will expose the following endpoints, to retailers only, to service Shared R
 * **Get DER For Service Point**: Obtain a list of DER data for a particular service point
 * **Get DER For Specific Service Points**: Obtain DER data for a specific set of service points.
 
-The endpoints above MUST be implemented by AEMO exactly as they would be by Data Holders designated for the energy sector unless explicitly indicated otherwise in the following sections.
+The endpoints above **MUST** be implemented by AEMO exactly as they would be by Data Holders designated for the energy sector unless explicitly indicated otherwise in the following sections.
 
 #### Secondary Base Path
 
@@ -27,25 +27,25 @@ would become the secondary endpoint:
 
 The following variations to the endpoints published by AEMO from the energy sector endpoints apply:
 
-* The _x-fapi-auth-date_ header MUST NOT be passed to AEMO and AEMO MUST NOT require this header
-* The _x-fapi-customer-ip-address_ header MUST NOT be passed to AEMO and AEMO MUST NOT require this header
-* The _x-cds-client-headers_ header MUST NOT be passed to AEMO and AEMO MUST NOT require this header
-* A new header named _x-cds-arrangement_ must be passed to AEMO for every invocation. This header should contain the arrangement ID for the consent that the request is being made under and will be used for tracing and audit purposes. This field MUST be populated but AEMO MUST NOT seek to validate the consent associated with the arrangement
+* The _x-fapi-auth-date_ header **MUST NOT** be passed to AEMO and AEMO **MUST NOT** require this header
+* The _x-fapi-customer-ip-address_ header **MUST NOT** be passed to AEMO and AEMO **MUST NOT** require this header
+* The _x-cds-client-headers_ header **MUST NOT** be passed to AEMO and AEMO **MUST NOT** require this header
+* A new header named _x-cds-arrangement_ must be passed to AEMO for every invocation. This header should contain the arrangement ID for the consent that the request is being made under and will be used for tracing and audit purposes. This field **MUST** be populated but AEMO **MUST NOT** seek to validate the consent associated with the arrangement
 * All occurrences of the _servicePointId_ field, whether in a request, a response, or as an input parameter (such as path parameter or query parameter) should be populated with the equivalent _NationalMeteringId_ in plain text
-* Fields in the links object for all responses MUST be translated by the Data Holder into
+* Fields in the links object for all responses **MUST** be translated by the Data Holder into
 values that are valid for a Data Recipient to be able to call back to the Data Holder
-* The *Get Service Points* endpoint MUST be changed from a GET to a POST and will have the same request payload as the *Get Usage For Specific Service Points* endpoint.
+* The *Get Service Points* endpoint **MUST** be changed from a GET to a POST and will have the same request payload as the *Get Usage For Specific Service Points* endpoint.
 
 #### Additional Requirements
 
 The following statements also apply to the endpoints published by AEMO:
 
 * General headers should be provided as if the request were coming from the primary Data Holder and not propagated from the call made by the Data Recipient
-* The _x-fapi-interaction-id_ header must be propagated from the Data Recipient call to AEMO to allow for end to end tracing. If not supplied by the Data Recipient, the primary Data Holder MUST create a unique value for the _x-fapi-interaction-id_ header before calling AEMO
+* The _x-fapi-interaction-id_ header must be propagated from the Data Recipient call to AEMO to allow for end to end tracing. If not supplied by the Data Recipient, the primary Data Holder **MUST** create a unique value for the _x-fapi-interaction-id_ header before calling AEMO
 * Endpoints that require knowledge of the NMIs that belong to the CDR Consumer have been excluded from the AEMO endpoint set. This includes *Get Bulk Usage* and *Get Bulk DER*. When a primary Data Holder is required to respond to these endpoints they should call the equivalent endpoint for specific service points and provide the specific list of NMIs to AEMO
-* Some primary Data Holders may interact with AEMO using multiple participant IDs. For these Data Holders it is possible that a single request from a CDR Consumer covering multiple NMIs would require multiple calls to AEMO if the NMIs were associated with multiple participant IDs owned by the Data Holder. In this scenario the retailer MUST call AEMO multiple times and aggregate the results before responding to the Data Recipient
+* Some primary Data Holders may interact with AEMO using multiple participant IDs. For these Data Holders it is possible that a single request from a CDR Consumer covering multiple NMIs would require multiple calls to AEMO if the NMIs were associated with multiple participant IDs owned by the Data Holder. In this scenario the retailer **MUST** call AEMO multiple times and aggregate the results before responding to the Data Recipient
 * If a request for usage data spans a time period when AEMO cannot definitively determine that the primary Data Holder was not in control of the NMI then:
-  * AEMO MUST NOT respond with an error
-  * AEMO MUST respond with the usage for the period that the primary Data Holder can be definitively determined to be in control of the NMI
-  * AEMO MUST NOT share data outside the period of control of the primary Data Holder
-* The primary Data Holder MUST ensure that the data requested and then shared with the Data Recipient is not outside the bounds of control of the specific CDR Consumer.
+  * AEMO **MUST NOT** respond with an error
+  * AEMO **MUST** respond with the usage for the period that the primary Data Holder can be definitively determined to be in control of the NMI
+  * AEMO **MUST NOT** share data outside the period of control of the primary Data Holder
+* The primary Data Holder **MUST** ensure that the data requested and then shared with the Data Recipient is not outside the bounds of control of the specific CDR Consumer.

slate/source/includes/secondary/_energy_security.md

@@ -7,7 +7,7 @@ For the energy sector requests for the following data clusters are Shared Respon
 * Energy Usage
 * Distributed Energy Resources.
 
-CDR requests for these data clusters to a Data Holder MUST be fulfilled by a request to AEMO.
+CDR requests for these data clusters to a Data Holder **MUST** be fulfilled by a request to AEMO.
 
 <h3 id="shared-responsibility_energy_security-profile">Security Profile</h3>
 

slate/source/includes/security/_client_authentication.md

@@ -2,11 +2,11 @@
 
 This section outlines how participants in the CDR regime will authenticate clients seeking access to endpoints.
 
-Note that, while **[[MTLS]](#nref-MTLS)** is utilised for transaction security and as a Holder of Key mechanism, the PKI Mutual TLS OAuth Client Authentication Method SHALL NOT be supported as the mechanism for client authentication.
+Note that, while **[[MTLS]](#nref-MTLS)** is utilised for transaction security and as a Holder of Key mechanism, the PKI Mutual TLS OAuth Client Authentication Method **SHALL NOT** be supported as the mechanism for client authentication.
 
 The following authentication methods are supported:
 
-* Data Holders SHALL authenticate the CDR Register client using one of the following Client Authentication methods: 
+* Data Holders **SHALL** authenticate the CDR Register client using one of the following Client Authentication methods: 
   * Self-signed JWT client assertion authenticated by the protected request endpoint according to [Self-signed JWT Client Authentication](#self-signed-jwt-client-authentication), or 
   * `private_key_jwt` authentication using `client_credentials` authorisation grant flow according to [Private Key JWT Client Authentication](#private-key-jwt-client-authentication).
 * Data Holders and the CDR Register **MUST** authenticate Data Recipient Software Products using the [Private Key JWT Client Authentication](#private-key-jwt-client-authentication) method.

slate/source/includes/security/endpoints/_cdr_arrangement_revocation.md

@@ -27,7 +27,7 @@ Content-Type: application/x-www-form-urlencoded
 **Data Holder Path:** The _cdr_arrangement_revocation_endpoint_ defined using OIDC Discovery.  
 **Data Recipient Software Product Path:** `<RecipientBaseUri>/arrangements/revoke` where `<RecipientBaseUri>` is registered with the CDR Register.
 
-Data Holders and Data Recipient Software Products MUST implement a CDR Arrangement Revocation endpoint that can be used to revoke an existing sharing arrangement.
+Data Holders and Data Recipient Software Products **MUST** implement a CDR Arrangement Revocation endpoint that can be used to revoke an existing sharing arrangement.
 
 <br/>
 
@@ -53,11 +53,11 @@ The location of the Data Holder CDR Arrangement Revocation endpoint is determine
 
 This endpoint will be implemented according to the following:
 
-* Data Holders MUST only support "CDR Arrangement Form Parameter" method.
-* Data Recipient Software Products MUST revoke consent by calling the CDR Arrangement Revocation endpoint with a valid CDR Arrangement ID.
-* Data Holders MUST publish their CDR Arrangement Revocation endpoint using their OpenID Provider Metadata Discovery endpoint.
-* Consent revocation MUST also revoke associated refresh and/or access tokens.
-* If the _cdr_arrangement_id_ is not related to the client making the call it MUST be rejected.
+* Data Holders **MUST** only support "CDR Arrangement Form Parameter" method.
+* Data Recipient Software Products **MUST** revoke consent by calling the CDR Arrangement Revocation endpoint with a valid CDR Arrangement ID.
+* Data Holders **MUST** publish their CDR Arrangement Revocation endpoint using their OpenID Provider Metadata Discovery endpoint.
+* Consent revocation **MUST** also revoke associated refresh and/or access tokens.
+* If the _cdr_arrangement_id_ is not related to the client making the call it **MUST** be rejected.
 
 
 > Non-Normative Example: Data Recipient endpoint  
@@ -126,12 +126,12 @@ This endpoint will be implemented according to the following:
 
 **Response Codes**
 
-The following responses are in addition to error responses covered by normative references. Error scenarios in the following table MUST use the error structure defined in the [Payload Conventions](#payload-conventions).
+The following responses are in addition to error responses covered by normative references. Error scenarios in the following table **MUST** use the error structure defined in the [Payload Conventions](#payload-conventions).
 
 Response Code | Situation | Description
 -- | -- | --
 204 No Content | Success | The sharing arrangement has been revoked successfully.
-422 Unprocessable Entity | Invalid Arrangement ID | The client submitted an invalid arrangement identifier or the identifier could not be found. The server MUST respond with [Invalid Consent Arrangement](#error-422-authorisation-invalid-arrangement).
+422 Unprocessable Entity | Invalid Arrangement ID | The client submitted an invalid arrangement identifier or the identifier could not be found. The server **MUST** respond with [Invalid Consent Arrangement](#error-422-authorisation-invalid-arrangement).
 
 
 

slate/source/includes/security/endpoints/_jwks.md

@@ -10,7 +10,7 @@ The requirements for the JWKS endpoint are specified in various sections of **[[
 
 This endpoint is used by the Data Holder to provide the public keys they will use when required.
 
-Data Holders MUST support a JWKS endpoint.
+Data Holders **MUST** support a JWKS endpoint.
 
 This endpoint does not require [CORS](#cors).
 
@@ -19,4 +19,4 @@ This endpoint does not require [CORS](#cors).
 
 In addition to **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** section 8.9 **from July 4th 2022**, the following requirements apply:
 
-* Data Holders and Data Recipients JWK sets MUST NOT contain multiple keys with the same _kid_.
+* Data Holders and Data Recipients JWK sets **MUST NOT** contain multiple keys with the same _kid_.

slate/source/includes/security/endpoints/_oidc_provider_configuration.md

@@ -56,7 +56,7 @@ Content-Type: application/json
 | Client Authentication Required| No|
 | Bearer Token Required| No|
 
-Data Holders MUST make their OpenID Provider Metadata available via a configuration endpoint as outlined in [Section 3 and 4 of the OpenID Connect Discovery standards](https://openid.net/specs/openid-connect-discovery-1_0.html) **[[OIDD]](#nref-OIDD)**.
+Data Holders **MUST** make their OpenID Provider Metadata available via a configuration endpoint as outlined in [Section 3 and 4 of the OpenID Connect Discovery standards](https://openid.net/specs/openid-connect-discovery-1_0.html) **[[OIDD]](#nref-OIDD)**.
 
 This endpoint does not require [CORS](#cors).
 

slate/source/includes/security/endpoints/_registration.md

@@ -1,6 +1,6 @@
 ### Dynamic Client Registration endpoints
 
-Data Holders MUST expose the following endpoints in accordance with **[[DCR]](#nref-DCR)**.
+Data Holders **MUST** expose the following endpoints in accordance with **[[DCR]](#nref-DCR)**.
 
 For more details of these endpoints see the [DCR APIs](#dcr-apis) section.
 
@@ -17,11 +17,11 @@ For additional statements on the operation of these endpoint during client regis
 
 Additional statements regarding these endpoints:
 
-* During registration management requests, Data Holders MUST validate that the scope of access tokens provided includes `cdr:registration`.
+* During registration management requests, Data Holders **MUST** validate that the scope of access tokens provided includes `cdr:registration`.
 * Registration requests and responses must conform to the specification in the [DCR APIs](#dcr-apis) section.
-* Any fields the Data Holder does not support MUST be ignored without error.
-* Registrations MUST only be updated via a PUT operation on the registration endpoint.
-* POST and PUT operations MUST accept the SSA payload.
+* Any fields the Data Holder does not support **MUST** be ignored without error.
+* Registrations **MUST** only be updated via a PUT operation on the registration endpoint.
+* POST and PUT operations **MUST** accept the SSA payload.
 * Update (PUT) operations are to be used for one of two scenarios:
   1. The client has updated their registration details on the CDR Register and updates this information to the data holder brands.
   2. A new version of the SSA has been released and the client updates this information to the data holder brands.

slate/source/includes/security/endpoints/_token.md

@@ -10,4 +10,4 @@ The requirements for the Token endpoint are specified in [section 3.3.3](https:/
 
 To obtain an Access Token, an ID Token, and a Refresh Token, the Data Recipient Software Product sends a Token Request to the Token endpoint.
 
-Data Holders MUST support a Token endpoint.
+Data Holders **MUST** support a Token endpoint.

slate/source/includes/security/endpoints/_token_introspection.md

@@ -7,11 +7,11 @@
 | Client Authentication Required | Yes |
 | Bearer Token Required | No |
 
-Data Holders MUST implement an Introspection endpoint to allow Data Recipient Software Products to determine the status and expiry date of Refresh Tokens. The requirements for an Introspection endpoint are described in [section 2](https://tools.ietf.org/html/rfc7662#section-2) of **[[RFC7662]](#nref-RFC7662)**.
+Data Holders **MUST** implement an Introspection endpoint to allow Data Recipient Software Products to determine the status and expiry date of Refresh Tokens. The requirements for an Introspection endpoint are described in [section 2](https://tools.ietf.org/html/rfc7662#section-2) of **[[RFC7662]](#nref-RFC7662)**.
 
-Introspection of Refresh Tokens MUST be supported.
+Introspection of Refresh Tokens **MUST** be supported.
 
-Introspection of Access Tokens and ID Tokens MUST NOT be supported.
+Introspection of Access Tokens and ID Tokens **MUST NOT** be supported.
 
 For currently active tokens, a Token Introspection endpoint Response **SHALL** include, at least, the following fields:
 
@@ -20,4 +20,4 @@ For currently active tokens, a Token Introspection endpoint Response **SHALL** i
 - _scope_: A JSON string containing a space-separated list of scopes associated with this token.
 - _cdr_arrangement_id_: A unique identifier of the CDR arrangement related to the authorisation.
 
-A Token Introspection endpoint Response MAY include claims defined in Section 2.2 of **[[RFC7662]](#nref-RFC7662)** but _username_ SHALL NOT be allowed.
+A Token Introspection endpoint Response **MAY** include claims defined in Section 2.2 of **[[RFC7662]](#nref-RFC7662)** but _username_ **SHALL NOT** be allowed.

slate/source/includes/security/endpoints/_token_revocation.md

@@ -9,8 +9,8 @@
 
 **Requirements for Data Holder implementations**
 
-Data Holders MUST implement a Token Revocation endpoint as described in [section 2](https://tools.ietf.org/html/rfc7009#section-2) of **[[RFC7009]](#nref-RFC7009)**.
+Data Holders **MUST** implement a Token Revocation endpoint as described in [section 2](https://tools.ietf.org/html/rfc7009#section-2) of **[[RFC7009]](#nref-RFC7009)**.
 
 The Revocation endpoint serves as a revocation mechanism that allows a Data Recipient Software Product to invalidate its tokens as required to allow for token clean up.
 
-Revocation of Refresh Tokens and Access Tokens MUST be supported.
+Revocation of Refresh Tokens and Access Tokens **MUST** be supported.