Merge pull request #244 from ConsumerDataStandardsAustralia/maintenan…

…ce/547

Maintenance/547

slate/source/includes/introduction/_fdo.md

@@ -46,5 +46,5 @@ Updated Get Energy Accounts V2 and Get Energy Account Detail V2 obligation dates
 |[Error Codes: Secondary Data Holder flag](#error-codes)|<ul><li>Data Holders **MAY** implement the `isSecondaryDataHolderError` field on **November 15 2022**</li><li>Affected Data Holders **MUST** implement `isSecondaryDataHolderError` field by **May 15 2023**</li></ul> | May 15th 2023 |
 |[Get Energy Accounts V2](#get-energy-accounts)|Data Holder **MUST** implement v2 of this endpoint by **April 14th 2023** | April 14th 2023 |
 |[Get Energy Account Detail V2](#get-energy-account-detail)|Data Holder **MUST** implement v2 of this endpoint by **April 14th 2023** | April 14th 2023 |
-|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.<br/><strong>Phase 3: Support Authorization Code Flow and Hybrid Flow</strong> includes, amongst other changes:<ul><li>Data Holders **MUST** support Authorization Code Flow</li><li>Data Holders **MUST** retire Hybrid Flow</li></ul> | April 14th 2023 |
+|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.<br/><strong>Phase 3: Support Authorization Code Flow and Hybrid Flow</strong> includes, amongst other changes:<ul><li>Data Holders **MUST** support Authorization Code Flow</li><li>Data Holders **MUST** support Hybrid Flow</li></ul> | April 14th 2023 |
 |[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.<br/><strong>Phase 4: Retire Hybrid Flow</strong>:<ul><li>Data Holders **MAY** retire Hybrid Flow</li></ul> | July 10th 2023 |

slate/source/includes/releasenotes/releasenotes.1.21.0.html.md

@@ -26,12 +26,15 @@ This release addresses the following change requests raised on [Standards Mainte
 
 ### Decision Proposals
 
-This release addresses the following Decision Proposals published on [Standards](https://github.com/ConsumerDataStandardsAustralia/standards/issues):
+This release addresses the following Decision Proposals published on [Standards](https://github.com/ConsumerDataStandardsAustralia/standards/issues):  
+
 - [Decision Proposal 282](https://github.com/ConsumerDataStandardsAustralia/standards/issues/282)
 
 
 ## Introduction
 
+|Change|Description|Link|
+|------|-----------|----|
 | Obligation Dates Schedule | [Decision Proposal 282](https://github.com/ConsumerDataStandardsAustralia/standards/issues/282): obligation date schedule from 7th April to 14th April 2023. | [Obligation Dates Schedule](../../includes/endpoint-version-schedule/#obligation-dates-schedule) |
 
 ## High Level Standards
@@ -41,6 +44,8 @@ No changes
 
 ## API End Points
 
+|Change|Description|Link|
+|------|-----------|----|
 | Get Energy Accounts V2 and Get Energy Account Detail V2 | [Decision Proposal 282](https://github.com/ConsumerDataStandardsAustralia/standards/issues/282): Updated obligation dates from 7th April to 14th April 2023 to align with the changed obligation mileston. | [Energy APIs](../../#energy-apis) |
 
 

slate/source/includes/security/_authentication_flows.md

@@ -56,10 +56,11 @@ In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authoris
 *	Data Holders **SHOULD** support Authorization Code Flow.
 
 **From April 14th 2023 (FAPI 1.0 Migration Phase 3),** the following requirements apply in addition to the FAPI 1.0 Migration Phase 2 requirements:  
-* Data Holders **MUST** support Authorization Code Flow.
+* Data Holders **MUST** support Authorization Code Flow.  
 * Data Holders **MUST** support the OIDC Hybrid Flow.
 
-**From July 10th 2023 (FAPI 1.0 Migration Phase 4),**  
+**From July 10th 2023 (FAPI 1.0 Migration Phase 4),**   
+
 * Data Holders **MAY** retire support for the OIDC Hybrid Flow.
 
 
@@ -102,11 +103,11 @@ Only a `response_type` (see [section 3.3](https://openid.net/specs/openid-connec
 
 The following statements are applicable for this flow:
 
-* Only a response_type (see [section 3.1](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth) of **[[OIDC]](#nref-OIDC)**) of code **SHALL** be allowed.
+* Only a `response_type` (see [section 3.1](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth) of **[[OIDC]](#nref-OIDC)**) of `code` **SHALL** be allowed.
 * Data Holders **MUST** also support **[[JARM]](#nref-JARM)** and **[[PKCE]](#nref-PKCE)**
 
 #### Data Holders
-Data Holders MUST support **[[JARM]](#nref-JARM)** in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#jarm).
+Data Holders **MUST** support **[[JARM]](#nref-JARM)** in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#jarm).
 
 > **JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)**
 > Data Holders **MAY** support Authorisation Response encryption.

slate/source/includes/security/_client_registration.md.erb

@@ -259,13 +259,11 @@ Updated ID Token encryption parameter descriptions
 |**grant_types**|	Required | Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. Supported values: **[client_credentials, authorization_code, refresh_token]**
 |**response_types**|	Required | Array of the OAuth 2.0 response type strings that the client can use at the authorization endpoint. **values: ["code", "code id_token"]**<br><br>Response type value “code” is required for Authorization Code Flow. Response type value “code id_token” is required for OIDC Hybrid Flow.
 |**application_type**|	Optional | Kind of the application. The only supported application type will be **web**
-|**id_token_signed_response_alg**| Required | Algorithm with which an id_token is to be signed</br></br>Supported values as constrained by **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. Required for both Authorization Code Flow (response_type “code”) and OIDC Hybrid Flow (response_type “code id_token”).
+|**id_token_signed_response_alg**| Required | Algorithm with which an id_token is to be signed</br></br>Supported values as constrained by **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. Required for both Authorization Code Flow (`response_type` “code”) and OIDC Hybrid Flow (`response_type` “code id_token”).
 |**id_token_encrypted_response_alg**| Required | JWE `alg` algorithm with which an id_token is to be encrypted.<br><br>Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow.
 |**id_token_encrypted_response_enc**| Required | JWE `enc` algorithm with which an id_token is to be encrypted.<br><br>Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow.
 |**authorization_signed_response_alg**| Conditional | The JWS alg algorithm required for signing authorization responses. If this is specified, the response will be signed using JWS and the configured algorithm. The algorithm “none” is not allowed.<br><br>Required if response_type of “code” is registered by the client.
-|**authorization_encrypted_response_alg**|Conditional|The JWE alg algorithm required for encrypting authorization responses.
-If unspecified, the default is that no encryption is performed.<br><br>Required if “authorization_encrypted_
-response_enc” is included.
+|**authorization_encrypted_response_alg**|Conditional|The JWE alg algorithm required for encrypting authorization responses. If unspecified, the default is that no encryption is performed.<br><br>Required if “authorization_encrypted_response_enc” is included.
 |**authorization_encrypted_response_enc**|Optional|The JWE enc algorithm required for encrypting authorization responses. If “authorization_encrypted_response_alg” is specified, the default for this value is “A128CBC-HS256”.
 |**request_object_signing_alg**| Optional | Algorithm which the ADR expects to sign the request object if a request object will be part of the authorization request sent to the Data Holder</br></br>If field not present in the request, data holders are expected to respond with an appropriate default value</br></br>Supported values as constrained by **[[FAPI-RW-Draft]](#nref-FAPI-RW-Draft)**
 |**software_statement**|	Required | Software statement assertion issued by the CDR Register
@@ -298,7 +296,7 @@ ID Token algorithm considerations remain relevant where the OIDC Hybrid Flow is
 + Added JARM response encryption considerations
 ```
 
-If Data Holders support authorisation response encryption, they **MUST** support, at a minimum, one of each of the following alg and enc algorithms:
+If Data Holders support authorisation response encryption, they **MUST** support, at a minimum, one of each of the following `alg` and `enc` algorithms:
 
 | Claim | Values
 |-- | --