diff --git a/slate/source/includes/introduction/_fdo.md b/slate/source/includes/introduction/_fdo.md index 83e28b4f..a9483b03 100644 --- a/slate/source/includes/introduction/_fdo.md +++ b/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)| | 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.
Phase 3: Support Authorization Code Flow and Hybrid Flow includes, amongst other changes: | April 14th 2023 | +|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.
Phase 3: Support Authorization Code Flow and Hybrid Flow includes, amongst other changes: | April 14th 2023 | |[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.
Phase 4: Retire Hybrid Flow: | July 10th 2023 | diff --git a/slate/source/includes/releasenotes/releasenotes.1.21.0.html.md b/slate/source/includes/releasenotes/releasenotes.1.21.0.html.md index f08c6946..c122e17c 100644 --- a/slate/source/includes/releasenotes/releasenotes.1.21.0.html.md +++ b/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) | diff --git a/slate/source/includes/security/_authentication_flows.md b/slate/source/includes/security/_authentication_flows.md index 8168adbb..583ddfe4 100644 --- a/slate/source/includes/security/_authentication_flows.md +++ b/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. diff --git a/slate/source/includes/security/_client_registration.md.erb b/slate/source/includes/security/_client_registration.md.erb index eb6fe003..b2dd239c 100644 --- a/slate/source/includes/security/_client_registration.md.erb +++ b/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"]**

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

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

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.

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.

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.

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.

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.

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

If field not present in the request, data holders are expected to respond with an appropriate default value

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 |-- | --