From 31d6b508971d34d0cbcc547d8f814db423eec1d4 Mon Sep 17 00:00:00 2001 From: James Bligh Date: Tue, 22 Aug 2023 13:04:19 +1000 Subject: [PATCH 01/47] Remove 1.25.0 diff statements --- .../additional20230717-90747-11hp2yy | 20 +++++++++++ slate/source/includes/_admin.md.erb | 26 -------------- slate/source/includes/_banking_apis.md.erb | 32 ----------------- slate/source/includes/_common_apis.md.erb | 4 --- slate/source/includes/_energy_apis.md.erb | 36 ------------------- slate/source/includes/_register.md.erb | 5 --- .../additional/candidates/telco_apis.md | 11 ------ .../introduction/_dependencies_schedule.md | 5 --- slate/source/includes/introduction/_fdo.md | 7 ---- .../includes/introduction/_references.md | 8 ----- .../nfrs/_data-recipient-requirements.md | 4 --- .../includes/nfrs/_traffic-thresholds.md | 5 --- .../security/_authentication_flows.md | 7 ---- .../security/_client_registration.md.erb | 15 -------- slate/source/includes/security/_overview.md | 5 --- .../includes/security/_request_object.md | 16 --------- slate/source/includes/security/_tokens.md | 24 ------------- .../includes/security/_transport_security.md | 4 +-- .../security/endpoints/_authorisation.md | 6 +--- .../endpoints/_oidc_provider_configuration.md | 22 ++++-------- .../includes/security/endpoints/_par.md | 12 ------- slate/source/includes/standards/_headers.md | 5 --- 22 files changed, 28 insertions(+), 251 deletions(-) create mode 100644 docs/includes/additional/additional20230717-90747-11hp2yy diff --git a/docs/includes/additional/additional20230717-90747-11hp2yy b/docs/includes/additional/additional20230717-90747-11hp2yy new file mode 100644 index 00000000..93415bd9 --- /dev/null +++ b/docs/includes/additional/additional20230717-90747-11hp2yy @@ -0,0 +1,20 @@ +

Additional Standards

+

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

+ +

These standards fall into three categories:

+ +
    +
  1. Candidate standards that are non-binding and stable
    2. +
  2. Draft standards that are non-binding but volatile as they are under development
    3. +
  3. Experimental standards that are transient and created to test concepts
    4. +
+

Candidate Standards

+

The Consumer Data Standards currently include the following candidate standards:

+ + +

Draft Standards

+

The Consumer Data Standards do not currently include any draft standards.

+

Experimental Standards

+

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/slate/source/includes/_admin.md.erb b/slate/source/includes/_admin.md.erb index 6f34c9de..5b6e6560 100644 --- a/slate/source/includes/_admin.md.erb +++ b/slate/source/includes/_admin.md.erb @@ -9,30 +9,4 @@ This provides an overview of CDS Administration Endpoints. Please note this API Admin OpenAPI Specification (YAML) -```diff -+ Adding v4 and v5 of the Get Metrics endpoint - -v4 changes are: -• Aligned types to standard CDR types -• Separated availability and TPS metric into aggregated, - authenticated and unauthenticed -• Error counts split by HTTP error code -• Added new authorisation metrics -• Added language to clarify that metrics are calculated at - the Data Holder brand level for Data Holders with multiple - brands - -v5 changes are: -• Performance metrics broken down by performance tier -• Include hourly metrics for performance metrics to align to NFRs -• Inclusion of aggregate metric for performance metrics -• Addition of abandonmentsByStage object to authorisation metrics - -Note that two typos were identified in the initial version of -1.25.0 published on 8th July that have now been corrected. These -are: -• Incorrect description of the ErrorMetricsV2 model -• Incorrect name of the preIdentification field -``` - <%= partial "includes/cds_admin.md" %> diff --git a/slate/source/includes/_banking_apis.md.erb b/slate/source/includes/_banking_apis.md.erb index d0593887..6ffeea82 100644 --- a/slate/source/includes/_banking_apis.md.erb +++ b/slate/source/includes/_banking_apis.md.erb @@ -10,38 +10,6 @@ This specification defines the APIs for Data Holders exposing Banking endpoints. Banking OpenAPI Specification (YAML) -```diff -Updated the versions of the following APIs: -+ Get Scheduled Payments For Account from v1 to v2 -+ Get Scheduled Payments Bulk from v1 to v2 -+ Get Scheduled Payments For Specific Accounts from v1 to v2 - - -Updated the following structures -from: -- ResponseBankingScheduledPaymentsList -- BankingScheduledPayment -- BankingScheduledPaymentSet -- BankingScheduledPaymentTo - -to: -+ ResponseBankingScheduledPaymentsListV2 -+ BankingScheduledPaymentV2 -+ BankingScheduledPaymentSetV2 -+ BankingScheduledPaymentToV2 - -Added the following to 'BankingScheduledPaymentToV2' structure: -+ 'digitalWallet' ENUM value to the toUType field -+ 'digitalWallet' object -+ 'BankingDigitalWalletPayee' schema for 'digitalWallet' object - -Replaced FAPI draft references with FAPI 1.0 Final references. -References pertain to the x-fapi-auth-date header. - -Typo correction for the Get Products API description, changing -"actual" to "actually" -``` - <%= partial "includes/cds_banking.md" %> <%= partial "includes/banking/_product_categories.md" %> <%= partial "includes/banking/_product_components.md" %> diff --git a/slate/source/includes/_common_apis.md.erb b/slate/source/includes/_common_apis.md.erb index 563569ad..3ec560c3 100644 --- a/slate/source/includes/_common_apis.md.erb +++ b/slate/source/includes/_common_apis.md.erb @@ -8,8 +8,4 @@ This specification defines the Common APIs that apply to Data Holders multiple s Common OpenAPI Specification (YAML) -```diff -Replaced FAPI draft references with FAPI 1.0 Final references. -References pertain to the x-fapi-auth-date header. -``` <%= partial "includes/cds_common.md" %> diff --git a/slate/source/includes/_energy_apis.md.erb b/slate/source/includes/_energy_apis.md.erb index eac47e30..223aa56a 100644 --- a/slate/source/includes/_energy_apis.md.erb +++ b/slate/source/includes/_energy_apis.md.erb @@ -8,40 +8,4 @@ This specification defines the APIs for Data Holders exposing Energy endpoints. Energy OpenAPI Specification (YAML) -```diff -Updated description of EnergyPaymentSchedule.digitalWallet.name field -from: -- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider -to: -+ The display name of the wallet as given by the customer, else a default value defined by the data holder - -Updated description of `EnergyPaymentSchedule.isTokenised` field to further clarify when it can be used - -Updated the versions of the following APIs: -+ Get Billing For Account from v1 to v2 -+ Get Bulk Billing from v1 to v2 -+ Get Billing For Specific Accounts from v1 to v2 - -Updated the following structures -from: -- EnergyBillingListResponse -- EnergyBillingTransaction -- EnergyBillingDemandTransaction -- EnergyBillingUsageTransaction - -to: -+ EnergyBillingListResponseV2 -+ EnergyBillingTransactionV2 -+ EnergyBillingDemandTransactionV2 -+ EnergyBillingUsageTransactionV2 - - -Added following ENUM values to EnergyBillingDemandTransaction.timeOfUseType field: -+ ALL_DAY -+ EXCESS - -Added following ENUM values to EnergyBillingUsageTransaction.timeOfUseType field: -+ ALL_DAY -``` - <%= partial "includes/cds_energy.md" %> diff --git a/slate/source/includes/_register.md.erb b/slate/source/includes/_register.md.erb index 49879b52..e2f8f7c4 100644 --- a/slate/source/includes/_register.md.erb +++ b/slate/source/includes/_register.md.erb @@ -38,9 +38,4 @@ These endpoints are exposed by the Register and consumed by Data Holders and Dat |**Production TLS**|https://api.cdr.gov.au| |**Production mTLS**|https://secure.api.cdr.gov.au| -```diff -Amended the jwks and well known endpoint paths to reflect actual -Register implementation -``` - <%= partial "includes/cds_register.md" %> diff --git a/slate/source/includes/additional/candidates/telco_apis.md b/slate/source/includes/additional/candidates/telco_apis.md index 364daf31..aefb3fe5 100644 --- a/slate/source/includes/additional/candidates/telco_apis.md +++ b/slate/source/includes/additional/candidates/telco_apis.md @@ -4,14 +4,3 @@ This specification defines the APIs for Data Holders exposing Telecommunications Telco OpenAPI Specification (JSON) Telco OpenAPI Specification (YAML) - -```diff -Updated description of TelcoPaymentScheduleDigitalWallet.name field -from: -- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider -to: -+ The display name of the wallet as given by the customer, else a default value defined by the data holder - -Replaced FAPI draft references with FAPI 1.0 Final references. -References pertain to the x-fapi-auth-date header. -``` diff --git a/slate/source/includes/introduction/_dependencies_schedule.md b/slate/source/includes/introduction/_dependencies_schedule.md index 0f34bdbf..8203c6da 100644 --- a/slate/source/includes/introduction/_dependencies_schedule.md +++ b/slate/source/includes/introduction/_dependencies_schedule.md @@ -1,10 +1,5 @@ ## Register Implementation Schedule -```diff -Removed the dependency schedule content for the Register APIs -and linked to the ACCC implementation schedule. -``` - The implementation of the Register APIs is managed by the ACCC. Their implementation schedule is [published here](https://consumerdataright.atlassian.net/wiki/spaces/DP/pages/30081043/Delivery+Dates). diff --git a/slate/source/includes/introduction/_fdo.md b/slate/source/includes/introduction/_fdo.md index 73062a98..caec1bca 100644 --- a/slate/source/includes/introduction/_fdo.md +++ b/slate/source/includes/introduction/_fdo.md @@ -4,13 +4,6 @@ The standards, as published from time to time, may include specific statements i The table below highlights these areas of the standards. -```diff -Removed legacy obligation dates more than 6 months in the past -Fixed spelling of "Register" - -Added FDOs for decision 288 and 303 -``` - |Section|Description|Applicable Date| |-------|-----------|---------------| |[Get Account Detail V1](#get-account-detail)|Data holders **MAY** obsolete version 1 of this end point from February 28th 2023. Data recipients **MUST** upgrade their implementations to use version 2 by this time|February 28th 2023| diff --git a/slate/source/includes/introduction/_references.md b/slate/source/includes/introduction/_references.md index dce5e536..20b61c70 100644 --- a/slate/source/includes/introduction/_references.md +++ b/slate/source/includes/introduction/_references.md @@ -1,13 +1,5 @@ ## Normative References -```diff -Removed legacy FAPI references: -- FAPI-R-Draft -- FAPI-RW-Draft - -Updated PAR references to refer to RFC9126 -``` - | **Reference** | **Description** | **Version** | | --- | --- | --- | | **[DCR]** | OAuth 2.0 Dynamic Client Registration Protocol: |Jul 2015 diff --git a/slate/source/includes/nfrs/_data-recipient-requirements.md b/slate/source/includes/nfrs/_data-recipient-requirements.md index b7feeb7b..e315496b 100644 --- a/slate/source/includes/nfrs/_data-recipient-requirements.md +++ b/slate/source/includes/nfrs/_data-recipient-requirements.md @@ -6,10 +6,6 @@ Data Recipient Software Products will be limited by the traffic thresholds docum - Services should schedule unattended calls to avoid high traffic periods - Unattended calls should be managed to avoid short term bursts of traffic -```diff -+ Added the Low Velocity Data Sets section -``` - ### Low Velocity Data Sets For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed. diff --git a/slate/source/includes/nfrs/_traffic-thresholds.md b/slate/source/includes/nfrs/_traffic-thresholds.md index 054f01b3..8fe719cf 100644 --- a/slate/source/includes/nfrs/_traffic-thresholds.md +++ b/slate/source/includes/nfrs/_traffic-thresholds.md @@ -22,11 +22,6 @@ For Unattended traffic the following traffic thresholds will apply for low traff For Unattended traffic during high traffic periods only best effort support is required. -```diff -Updated the static site wide TPS thresholds with a graduated set of -thresholds depending on the number of active authorisations established -with the data holder -``` For secure traffic (both Customer Present and Unattended) the following traffic thresholds will apply: - For Data Holders with 0 to 10,000 active authorisations, 150 peak TPS total across all consumers diff --git a/slate/source/includes/security/_authentication_flows.md b/slate/source/includes/security/_authentication_flows.md index 3da6b18e..34414d98 100644 --- a/slate/source/includes/security/_authentication_flows.md +++ b/slate/source/includes/security/_authentication_flows.md @@ -34,9 +34,6 @@ In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authoris - offering additional or alternative services - reference or inclusion of other documents -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` * Data Holders **MUST** support FAPI 1.0 Advanced Profile (**[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**). * Data Holders **MUST** support Authorization Code Flow. * Data Holders **MUST** support the OIDC Hybrid Flow. @@ -52,10 +49,6 @@ The following statements are applicable to both the OIDC Hybrid Flow and Authori - Data Recipient Software Products **SHOULD** record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration. -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - * Data Recipient Software Products **SHOULD NOT** reuse "authorization_code" values, and if reused, it will be rejected. * Data Recipient Software Products **MAY** send requests with a "x-fapi-customer-ip-address" header containing a valid IPv4 or IPv6 address. * Data Recipient Software Products **MUST** support FAPI 1.0 Advanced Profile (**[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**). diff --git a/slate/source/includes/security/_client_registration.md.erb b/slate/source/includes/security/_client_registration.md.erb index 821f614d..b9c31840 100644 --- a/slate/source/includes/security/_client_registration.md.erb +++ b/slate/source/includes/security/_client_registration.md.erb @@ -8,10 +8,6 @@ Data Recipients register with Data Holders according to **[[DCR]](#nref-DCR)** t As per **[[DCR]](#nref-DCR)**, a Software Statement is defined in as: _A digitally signed JSON Web Token (JWT) created in accordance with **[[JWT]](#nref-JWT)** that asserts metadata values about the client software_ > An SSA is a digitally signed JSON Web Token (JWT) created in accordance with **[[JWT]](#nref-JWT)** that asserts metadata values about the client software. -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - Such that: * The CDR Register **MUST** issue Software Statements to **active** Data Recipients for **active** Software Products @@ -232,9 +228,6 @@ Accept: application/json } ``` -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` To register with a Data Holder, the Data Recipient sends an HTTP POST to the Data Holder registration endpoint. * The request **MUST** be presented in the format of a **[[RFC7519]](#nref-RFC7519)** compliant JWT. @@ -243,10 +236,6 @@ To register with a Data Holder, the Data Recipient sends an HTTP POST to the Dat The client registration request **MUST** contain the following claims in the JWT payload unless designated as Optional: -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - | Claim | Required | Description |--------------|-------|----------------------------------------------------------------------------------------------- |**iss**| Required | Contains the identifier for the Data Recipient Software Product (SoftwareProductId) as defined in the CDR Register @@ -284,10 +273,6 @@ Data Holders **MUST** support at a minimum, 1 algorithm for each claim. Data Recipients **MUST** support all the algorithms used in the ecosystem to ensure they can communicate with all Data Holders. -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - ID Token algorithm considerations remain relevant where the OIDC Hybrid Flow is leveraged as defined in the Consumer Data Standards and in accordance with sections [5.1.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature), [5.2.2.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-1), and [5.2.3.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-2) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. #### JARM Response Encryption Considerations diff --git a/slate/source/includes/security/_overview.md b/slate/source/includes/security/_overview.md index 674447bd..11eb767b 100644 --- a/slate/source/includes/security/_overview.md +++ b/slate/source/includes/security/_overview.md @@ -1,16 +1,11 @@ ## Overview - -```diff -Removed legacy phasing of FAPI draft specifications. Only FAPI 1.0 Final is relied upon. -``` This information security profile builds upon the foundations of the [Financial-grade API Advanced Profile](https://openid.net/specs/openid-financial-api-part-2-1_0.html) **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** and other standards relating to [Open ID Connect 1.0](http://openid.net/specs/openid-connect-core-1_0.html) **[[OIDC]](#nref-OIDC)**. For information on the specific normative references that underpin this profile refer to the [Normative References section](#normative-references). - ### Symbols and Abbreviated terms - **API**: Application Programming Interface - **CA**: Certificate Authority diff --git a/slate/source/includes/security/_request_object.md b/slate/source/includes/security/_request_object.md index fc5f162a..f06776f6 100644 --- a/slate/source/includes/security/_request_object.md +++ b/slate/source/includes/security/_request_object.md @@ -36,10 +36,6 @@ > Non-Normative Example - FAPI 1.0 Final Phase 3 Obligation -```diff -+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0 -``` - ``` #Decoded Request Object JWT @@ -75,10 +71,6 @@ } ``` -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - The Request Object is a signed and encoded JWT specified in [section 6.1](https://openid.net/specs/openid-connect-core-1_0.html#RequestObject) of **[OIDC]**. As per **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server), the `request` parameter **MUST** be present on requests to the **[OIDC]** Hybrid Authorisation End Point. The Request Object enables **[OIDC]** requests to be passed in a single and self-contained parameter. Request Objects **MUST** be signed by Data Recipient Software Products as specified in [section 8.6](https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. @@ -124,10 +116,6 @@ In addition: Data Holders **MUST** support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to **[[PAR]](#nref-PAR)**. -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - * Data Holders **MUST** support **[[RFC9126]](#nref-RFC9126)** (PAR) using **[[PKCE]](#nref-PKCE)** (**[[RFC7636]](#nref-RFC7636)**) with S256 as the code challenge method in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server). * Data Holders **MUST** require PAR for authorisation request data in accordance with **[[RFC9126]](#nref-RFC9126)** where "require_pushed_authorization_requests" parameter is set to "true". * Data Holders **MUST** require the request object to contain an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server). @@ -137,10 +125,6 @@ Removed legacy phasing requirements for FAPI 1.0 Final #### Data Recipient Software Products -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - * Data Recipients Software Products **MUST** send request object containing a "nbf" claim and an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim. * Data Recipient Software Products **MUST** ONLY use a "request_uri" value once * Data Recipients **MUST** ONLY send authorisation request data using **[[RFC9126]](#nref-RFC9126)** (PAR) and use **[[PKCE]](#nref-PKCE)** (**[[RFC7636]](#nref-RFC7636)**) in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. diff --git a/slate/source/includes/security/_tokens.md b/slate/source/includes/security/_tokens.md index 38a99568..d1d2e520 100644 --- a/slate/source/includes/security/_tokens.md +++ b/slate/source/includes/security/_tokens.md @@ -39,10 +39,6 @@ ID Tokens are specified in [section 2](https://openid.net/specs/openid-connect-c #### Baseline ID Token requirements -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - In addition to the mandatory claims specified in [section 2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) of the **[[OIDC]](#nref-OIDC)** standard, required claims for ID Tokens as part of Hybrid Flow authentication **MUST** align to [section 3.3](https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth) (Authentication using the Hybrid Flow) of the **[[OIDC]](#nref-OIDC)** standards and [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server) and [section 8.4.3](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-response-parameter-injection-attack) of the **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** profile. ID Tokens **MUST** be signed by Data Holders as specified in [section 8.6](https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. @@ -50,19 +46,12 @@ ID Tokens **MUST** be signed by Data Holders as specified in [section 8.6](https #### OIDC Hybrid Flow requirements -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - In accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**, ID Tokens **MUST** be signed and encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point. The ID Token returned from the Authorisation End Point **MUST NOT** contain any Personal Information (PI) claims. ##### Hashing value for state and authorisation code -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` The following requirements apply to the OIDC Hybrid Flow: * The `c_hash` value **MUST** be generated according to [section 3.3.2.11](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken) of **[[OIDC]](#nref-OIDC)**. @@ -80,10 +69,6 @@ An Access Token **MUST** expire between **2 minutes** to **10 minutes** after th The process for refreshing an Access Token is described in [section 12.1](https://openid.net/specs/openid-connect-core-1_0.html#RefreshingAccessToken) of **[[OIDC]](#nref-OIDC)**. -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - * Data Holders **MUST** reject token request with an authorization code (Section 1.3.1 of **[[RFC6749]](#nref-RFC6749)**) if it has been previously used @@ -96,10 +81,6 @@ The expiration time for a Refresh Token **MUST** be set by the Data Holder. Refresh Token expiration **MAY** be any length of time greater than 28 days but **MUST NOT** exceed the end of the duration of sharing consented to by the Consumer. -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - * Data Holders **MUST NOT** cycle refresh tokens (rotation). In other words, Refresh Tokens **SHOULD** be issued with an "exp" equal to the sharing duration authorised by the Customer. ### Token Expiry @@ -107,9 +88,4 @@ The expiry time for issued access tokens and refresh tokens **MUST** be determin In order to achieve this: -```diff -Removed legacy phasing requirements for FAPI 1.0 Final -``` - - The Data Holder **MUST** indicate the lifetime in seconds of the access token in the `expires_in` field of the JSON object returned by the token end-point (see [section 4.2.2] (https://tools.ietf.org/html/rfc6749#section-4.2.2) of **[[OAUTH2]](#nref-OAUTH2)**). - diff --git a/slate/source/includes/security/_transport_security.md b/slate/source/includes/security/_transport_security.md index ef308bc5..b69ef042 100644 --- a/slate/source/includes/security/_transport_security.md +++ b/slate/source/includes/security/_transport_security.md @@ -24,9 +24,7 @@ OAUTB SHALL NOT be supported due to a lack industry support. **[[MTLS]](#nref-MTLS)** HoK allows issued tokens to be bound to a client certificate as specified in [section 3](https://tools.ietf.org/id/draft-ietf-oauth-mtls-07.html#SenderConstrainedAccess) of **[[MTLS]](#nref-MTLS)**. ### Ciphers -```diff -Replaced FAPI draft RW references with FAPI 1.0 Final Advanced references. References pertain to the TLS considerations. -``` + Only the following cipher suites SHALL be permitted in accordance with [section 8.5](https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**: - TLS\_DHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 diff --git a/slate/source/includes/security/endpoints/_authorisation.md b/slate/source/includes/security/endpoints/_authorisation.md index 50c0706d..a5136149 100644 --- a/slate/source/includes/security/endpoints/_authorisation.md +++ b/slate/source/includes/security/endpoints/_authorisation.md @@ -55,7 +55,7 @@ Host: www.holder.com.au > Non-Normative Example - FAPI 1.0 Final Phase 3 Obligation > This example demonstrates how an ADR may send a staged authorisation request (using PAR) in the back-channel to the Data Holder. -> +> > It demonstrates a FAPI 1.0 Final compliant authorisation request using the PAR to first submit the authorisation request object. ``` @@ -76,10 +76,6 @@ Host: www.holder.com.au | Client Authentication Required| No| | Bearer Token Required| No| -```diff -Replaced FAPI draft references with FAPI 1.0 Final references -``` - The requirements for the Authorisation End Point are specified in [section 3.3.2](https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthorizationEndpoint) of **[[OIDC]](#nref-OIDC)** and further specified under section [5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**. This end point is invoked as part of the [Hybrid Authentication flow](#hybrid-flow). This endpoint does not require [CORS](https://consumerdatastandardsaustralia.github.io/standards/#cors). diff --git a/slate/source/includes/security/endpoints/_oidc_provider_configuration.md b/slate/source/includes/security/endpoints/_oidc_provider_configuration.md index 525522e7..00328234 100644 --- a/slate/source/includes/security/endpoints/_oidc_provider_configuration.md +++ b/slate/source/includes/security/endpoints/_oidc_provider_configuration.md @@ -2,10 +2,6 @@ > Non-Normative Example -```diff -+ Adds examples for all metadata parameters required by the Data Standards and upstream normative references -``` - ``` ## Request @@ -36,18 +32,18 @@ Content-Type: application/json "token_endpoint_auth_methods_supported": ["private_key_jwt"], "token_endpoint_auth_signing_alg_values_supported": ["ES256", "PS256"], "userinfo_endpoint": "https://www.dh.com.au/userinfo", - + "code_challenge_methods_supported": "S256", "introspection_endpoint": "https://www.dh.com.au/introspect", "revocation_endpoint": "https://www.dh.com.au/revoke", - + "tls_client_certificate_bound_access_tokens": true, "pushed_authorization_request_endpoint": "https://data.holder.com.au/par", "require_pushed_authorization_requests": true, - + "authorization_encryption_alg_values_supported": ["RSA-OAEP", "RSA-OAEP-256"], - + "authorization_encryption_enc_values_supported": ["A256GCM", "A128CBC-HS256"], "authorization_signing_alg_values_supported": ["ES256", "PS256"], @@ -66,11 +62,6 @@ Data Holders MUST make their OpenID Provider Metadata available via a configurat This endpoint does not require [CORS](https://consumerdatastandardsaustralia.github.io/standards/#cors). -```diff -Replaced FAPI draft references with FAPI 1.0 Final references - -+ Adds all metadata parameters required by the Data Standards and upstream normative references -``` At a minimum, the Data Holder metadata **MUST** include: **[[OIDD]](#nref-OIDD)** @@ -81,11 +72,11 @@ At a minimum, the Data Holder metadata **MUST** include: - `grant_types_supported`: The list of the OAuth 2.0 Grant Type values supported - `id_token_encryption_alg_values_supported`: The list of the supported JWE algorithms for securing the issued ID tokens. Must conform to **[[FAPI-RW-Draft]](#nref-FAPI-RW-Draft)** and **[[OIDD]](#nref-OIDD)**. Required for Data Holders supporting OIDC Hybrid Flow - `id_token_encryption_enc_values_supported`: The list of the supported JWE encryption methods for securing the issued ID tokens. Required for Data Holders supporting OIDC Hybrid Flow -- `id_token_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported +- `id_token_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported - `issuer`: URL that the Data Holder asserts as its Issuer Identifier - `jwks_uri`: The JSON Web Key Set for the data holder - `registration_endpoint`: URL of the Client Registration End Point -- `request_object_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported for signing request objects. +- `request_object_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported for signing request objects. - `response_modes_supported`: The list of the OAuth 2.0 `response_mode` values supported - `response_types_supported`: The list of the OAuth 2.0 `response_type` values supported - `scopes_supported`: The list of supported scopes @@ -122,4 +113,3 @@ Where Data Holders support authorisation response encryption according to **[[JA In addition, the Data Holder metadata **MUST** also include: - `cdr_arrangement_revocation_endpoint`: The URL of the CDR Arrangement Revocation End Point for consent revocation - diff --git a/slate/source/includes/security/endpoints/_par.md b/slate/source/includes/security/endpoints/_par.md index bd1ff1dd..a0419401 100644 --- a/slate/source/includes/security/endpoints/_par.md +++ b/slate/source/includes/security/endpoints/_par.md @@ -1,10 +1,6 @@ ### Pushed Authorisation End Point -```diff -Updated non-normtative example to use RFC9126, not the draft PAR specification -``` - > Non-Normative Example > Utilising RFC9126 and OIDC Hybrid Flow @@ -94,10 +90,6 @@ request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey... > Decoded Request - FAPI 1.0 Final Phase 3 Obligation This example shows an authorisation request using the Authorisation Code Flow (FAPI 1.0 migration Phase 3) -```diff -+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0 -``` - ``` { "iss": "s6BhdRkqt3", @@ -183,10 +175,6 @@ eyJraWQiOiIwZWQ3YTNkZi1hMGJlLTRhZjQtOTk0YS1jNDBhODc0ODQwNjMiLCJhbGciOiJQUzI1NiJ9 Data Holders **MUST** support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to **[[PAR]](#nref-PAR)**. -```diff -- Removed legacy phasing requirements for FAPI 1.0 Final using PAR -``` - Data Recipient Software Products **MUST** send authorisation requests using **[[PAR]](#nref-PAR)** if supported by the Data Holder. The Data Holder response provides the Data Recipient Software Product with a Request URI in the response. The Request URI is then passed to the Data Holder’s Authorisation End Point to initiate an authorisation flow. diff --git a/slate/source/includes/standards/_headers.md b/slate/source/includes/standards/_headers.md index 20bfe38f..65e0dde3 100644 --- a/slate/source/includes/standards/_headers.md +++ b/slate/source/includes/standards/_headers.md @@ -28,11 +28,6 @@ Supported HTTP headers, and their usage, for the standards are as laid out in th `Accept-Encoding: charset=UTF-8` `Accept: AppliCAtion/JSon;Charset=uTf-8` -```diff -Replaced FAPI draft references with FAPI 1.0 Final references. -References pertain to the x-fapi-auth-date header. -``` - Header Field | Description | Mandatory? -------------|-------------|----------- **Content-Type** | Standard HTTP Header. Represents the format of the payload provided in the request. The media type must be set to `application/json`. Mandatory for PUT and POST calls.| Conditional From 7d5852dd5670fe24b4a90bc9b3684503f3f7ad48 Mon Sep 17 00:00:00 2001 From: James Bligh Date: Tue, 22 Aug 2023 13:08:07 +1000 Subject: [PATCH 02/47] Rebuild --- .../additional20230710-41538-1hep9lq | 20 -- .../additional20230717-90747-11hp2yy | 20 -- .../additional20230717-92036-rywnu1 | 20 -- .../additional20230721-17819-179l1ax | 20 -- ...2lz7rg => additional20230822-11018-vk1vhm} | 0 .../includes/additional/candidates/telco.html | 10 +- .../includes/additional/candidates/telco_apis | 9 - docs/includes/nfrs | 11 +- docs/index.html | 254 +++++------------- 9 files changed, 71 insertions(+), 293 deletions(-) delete mode 100644 docs/includes/additional/additional20230710-41538-1hep9lq delete mode 100644 docs/includes/additional/additional20230717-90747-11hp2yy delete mode 100644 docs/includes/additional/additional20230717-92036-rywnu1 delete mode 100644 docs/includes/additional/additional20230721-17819-179l1ax rename docs/includes/additional/{additional20230710-41010-2lz7rg => additional20230822-11018-vk1vhm} (100%) diff --git a/docs/includes/additional/additional20230710-41538-1hep9lq b/docs/includes/additional/additional20230710-41538-1hep9lq deleted file mode 100644 index 93415bd9..00000000 --- a/docs/includes/additional/additional20230710-41538-1hep9lq +++ /dev/null @@ -1,20 +0,0 @@ -

Additional Standards

-

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

- -

These standards fall into three categories:

- -
    -
  1. Candidate standards that are non-binding and stable
    2. -
  2. Draft standards that are non-binding but volatile as they are under development
    3. -
  3. Experimental standards that are transient and created to test concepts
    4. -
-

Candidate Standards

-

The Consumer Data Standards currently include the following candidate standards:

- - -

Draft Standards

-

The Consumer Data Standards do not currently include any draft standards.

-

Experimental Standards

-

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/docs/includes/additional/additional20230717-90747-11hp2yy b/docs/includes/additional/additional20230717-90747-11hp2yy deleted file mode 100644 index 93415bd9..00000000 --- a/docs/includes/additional/additional20230717-90747-11hp2yy +++ /dev/null @@ -1,20 +0,0 @@ -

Additional Standards

-

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

- -

These standards fall into three categories:

- -
    -
  1. Candidate standards that are non-binding and stable
    2. -
  2. Draft standards that are non-binding but volatile as they are under development
    3. -
  3. Experimental standards that are transient and created to test concepts
    4. -
-

Candidate Standards

-

The Consumer Data Standards currently include the following candidate standards:

- - -

Draft Standards

-

The Consumer Data Standards do not currently include any draft standards.

-

Experimental Standards

-

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/docs/includes/additional/additional20230717-92036-rywnu1 b/docs/includes/additional/additional20230717-92036-rywnu1 deleted file mode 100644 index 93415bd9..00000000 --- a/docs/includes/additional/additional20230717-92036-rywnu1 +++ /dev/null @@ -1,20 +0,0 @@ -

Additional Standards

-

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

- -

These standards fall into three categories:

- -
    -
  1. Candidate standards that are non-binding and stable
    2. -
  2. Draft standards that are non-binding but volatile as they are under development
    3. -
  3. Experimental standards that are transient and created to test concepts
    4. -
-

Candidate Standards

-

The Consumer Data Standards currently include the following candidate standards:

- - -

Draft Standards

-

The Consumer Data Standards do not currently include any draft standards.

-

Experimental Standards

-

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/docs/includes/additional/additional20230721-17819-179l1ax b/docs/includes/additional/additional20230721-17819-179l1ax deleted file mode 100644 index 93415bd9..00000000 --- a/docs/includes/additional/additional20230721-17819-179l1ax +++ /dev/null @@ -1,20 +0,0 @@ -

Additional Standards

-

The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.

- -

These standards fall into three categories:

- -
    -
  1. Candidate standards that are non-binding and stable
    2. -
  2. Draft standards that are non-binding but volatile as they are under development
    3. -
  3. Experimental standards that are transient and created to test concepts
    4. -
-

Candidate Standards

-

The Consumer Data Standards currently include the following candidate standards:

- - -

Draft Standards

-

The Consumer Data Standards do not currently include any draft standards.

-

Experimental Standards

-

The experimental standards developed by the Data Standards Body are developed in this GitHub repository and are published here.

diff --git a/docs/includes/additional/additional20230710-41010-2lz7rg b/docs/includes/additional/additional20230822-11018-vk1vhm similarity index 100% rename from docs/includes/additional/additional20230710-41010-2lz7rg rename to docs/includes/additional/additional20230822-11018-vk1vhm diff --git a/docs/includes/additional/candidates/telco.html b/docs/includes/additional/candidates/telco.html index e4499e68..e2ae31dc 100644 --- a/docs/includes/additional/candidates/telco.html +++ b/docs/includes/additional/candidates/telco.html @@ -609,15 +609,7 @@

Telco APIs