Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify Transaction Security requirements #654

Closed
nils-work opened this issue Jul 26, 2024 · 0 comments
Closed

Clarify Transaction Security requirements #654

nils-work opened this issue Jul 26, 2024 · 0 comments
Assignees
Labels
Non-breaking change A change that is not expected to result in a new endpoint version. Operational Security Change or question related to the information security profile

Comments

@nils-work
Copy link
Member

Description

Sections of the documentation regarding transaction security and CDR certificate requirements appear to be unclear.

Intention and Value of Change

To improve the documentation to ensure the requirements are clear and that endpoints can be accessed correctly.

Area Affected

Sections of the Security Profile related to Transaction security, Certificate management and Partcipant endpoints.

Change Proposed

The following changes -

In the Security Profile -> Transaction Security -> Use of MTLS section:

- End points for transferring CDR Data that are classified as not requiring authentication do not require the use of [MTLS].
+ Endpoints for transferring CDR Data that are classified as not requiring authentication (i.e. public endpoints) or those specified as TLS, MUST NOT use [MTLS].

In the Security Profile -> Certificate Management -> Issued by the Register for Data Holders section:

- Server Certificate(s) | Certificate is issued to a FQDN Secures the following endpoints: - Resource endpoints - InfoSec endpoints - Admin endpoints
+ Server Certificate(s) | Certificate is issued to a FQDN. Secures the endpoints as detailed in [Participant endpoints]

In the Security Profile -> Certificate Management -> Issued by the Register CA for Data Recipients section:

- Server Certificate(s) | Certificate is issued to a FQDN. Secures the following: - CDR Arrangement Revocation endpoint - JWKS endpoint
- ADRs may choose to secure their [endpoints] with the Register CA issued certificate or a certificate issued by a public CA
+ Server Certificate(s) | Certificate is issued to a FQDN. Not currently required by Data Recipients.

In the Security Profile -> Security Endpoints -> Dynamic Client Registration Endpoints section:
In the table heading row:

- TLS-MA
+ MTLS

In the Security Profile -> Security Endpoints -> Participant Endpoints section:

Participants will be required to register base URIs against each of their brands to facilitate the implementation of the Consumer Data Standards.

+ Endpoints specified as MTLS MUST be configured according to the [Certificate Trust Model] in the [Certificate Management] section.
+ Endpoints specified as TLS MUST be configured with a certificate issued by a public CA accepted by major web browsers.

and the following changes to the table (highlighted in the image below):

  1. Add a Transaction Security column to specify the high-level requirement for each Base URI
    1. PublicBaseUri: TLS
    2. ResourceBaseUri: MTLS
    3. InfoSecBaseUri: TLS
    4. AdminBaseUri: MTLS
    5. ExtensionBaseUri: TLS/MTLS (depending on extension requirements)
    6. RevocationUri: TLS
    7. RecipientBaseUri: TLS
    8. JwksUri: TLS (for both DH and ADR)
  2. For ResourceBaseUri and RecipientBaseUri, change 'This should' to 'This MUST'
  3. Clarify that the InfoSecBaseUri only provides reference to the OIDC Discovery endpoint over TLS
  4. Provide references to usage of the different JwksUri values for Data Holders and Data Recipients

image

@nils-work nils-work added Security Change or question related to the information security profile Operational labels Aug 7, 2024
@nils-work nils-work added the Non-breaking change A change that is not expected to result in a new endpoint version. label Oct 23, 2024
@nils-work nils-work self-assigned this Nov 18, 2024
nils-work added a commit to ConsumerDataStandardsAustralia/standards-staging that referenced this issue Nov 18, 2024
nils-work added a commit to ConsumerDataStandardsAustralia/standards that referenced this issue Dec 18, 2024
* Created 1.32.0 branch base

* Staging #429 - Refactor Banking API spec

Addresses: ConsumerDataStandardsAustralia/standards-staging#429

* Create 1.33.0 branch base

* Updated refresh token expiry requirements related to Standards Maintenance issue #667

* Made links relative to avoid page refresh

Addresses: ConsumerDataStandardsAustralia/standards-staging#435 (comment)

* Added and updated servers in specs and examples

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#663 (comment)

* Link to specific comment

* Remove scheme from host field

* Clarified 'CDR Arrangement JWT method' details

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#663 (comment)

* Updated Reporting Requirements section

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#663 (comment)

* Replaced 'must' with 'MUST' in some headers

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#473 (comment)

* Applied consistent styling

Addresses: ConsumerDataStandardsAustralia/standards-staging#442

* Key word styling

Addresses: ConsumerDataStandardsAustralia/standards-staging#443

* Move note to correct section

* Corrected typos, updated styling

Addresses: ConsumerDataStandardsAustralia/standards-staging#431

* Staging #429 - Refactor Banking API spec

Addresses: ConsumerDataStandardsAustralia/standards-staging#429

* Update MTLS section 3 link

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#663 (comment)

* Clarify retirement date statements

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#663 (comment)

* Updated Obligation Date Schedule

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#661

* Clarified transaction security requirements

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#654

* Updated field descriptions

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#655

* Updated CX Standards

Addresses: #350

* Updated Normative References

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#675

* Tidied table formatting

* Get Product Detail v5 with LVR constraints

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#657

* Rename file to prevent generated version

Addresses: ConsumerDataStandardsAustralia/standards-staging#463

* Adjusted values to align format

* Corrected Date Schedule

* Standards Maintenance 664: Support for additional NPP service overlays and all versions

* Added diff for FDO table

* Change CDS links to DSB

Addresses: ConsumerDataStandardsAustralia/standards-staging#468

* Closed list items in unordered list

* Minor corrections

* Updates

* Minor updates

- customer > consumer
- obligation sequence

* Deprecated OiDC Hybrid Flow with retirement date set for May 12th 2025

* Add condition

* Updated diff comment for OIDC hybrid flow to indicate it is deprecated

* Update get-transaction-detail-v1.html.md

* Apply dates, logo and correct merge differences

* Rebuild

* Rebuild specs

* Minor corrections

* Update obligation table

---------

Co-authored-by: Mark Verstege <[email protected]>
@nils-work nils-work moved this from In Progress: Staging to Awaiting Chair Approval in Data Standards Maintenance Dec 18, 2024
@nils-work nils-work moved this from Awaiting Chair Approval to Done in Data Standards Maintenance Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking change A change that is not expected to result in a new endpoint version. Operational Security Change or question related to the information security profile
Projects
Status: Done
Development

No branches or pull requests

1 participant