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

Maint #654 - Clarified transaction security requirements #458

Merged
merged 2 commits into from
Dec 16, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ This release addresses the following minor defects raised on [Standards Staging]

This release addresses the following change requests raised on [Standards Maintenance](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues):

- [Standards Maintenance #XXX - Title](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/XXX)
- [Standards Maintenance #654 - Clarify Transaction Security requirements](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/654)


### Decision Proposals
Expand All @@ -34,7 +34,6 @@ This release addresses the following Decision Proposals published on [Standards]
|Change|Description|Link|
|------|-----------|----|
| Change summary | [**Standards Staging #XXX**](https://github.com/ConsumerDataStandardsAustralia/standards-staging/issues/XXX): Change detail | [Standards section](../../#section)
| Change summary | [**Standards Maintenance #XXX**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/XXX): Change detail | [Standards section](../../#section)
| Change summary | [**Decision Proposal #XXX**](https://github.com/ConsumerDataStandardsAustralia/standards/issues/XXX): Change detail | [Standards section](../../#section)


Expand All @@ -56,6 +55,7 @@ This release addresses the following Decision Proposals published on [Standards]
## Information Security Profile
|Change|Description|Link|
|------|-----------|----|
| Clarified transaction security requirements | [**Standards Maintenance #654**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/654): Clarified sections referring to TLS and MTLS requirements. | [Transaction Security](../../#transaction-security)<br>[Certificate Management](../../#certificate-management)<br>[Dynamic Client Registration Endpoints](../../#dynamic-client-registration-endpoints)<br>[Participant Endpoints](../../#participant-endpoints)


## Register Standards
Expand Down
10 changes: 7 additions & 3 deletions slate/source/includes/security/_certificate_management.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,23 @@

## Certificate Management

```diff
Clarified Server Certificate statements for Data Holders and Data Recipients and referred to Participant endpoints detail
```

### Issued by the Register for Data Holders
Certificate | Function | Notes
-----------|------------------------------------------|------------------------------
|**Server Certificate(s)**| Certificate is issued to a FQDN</br></br>Secures the following endpoints:</br>- Resource endpoints</br>- InfoSec endpoints</br>- Admin endpoints | It will be up to the DH on how these endpoints are segregated. They may all be on the one domain (so only one certificate required) or could be separated.
| <span style="white-space: nowrap;">**Server Certificate(s)**</span> | Certificate is issued to a FQDN.<br><br>Secures the endpoints as detailed in [Participant endpoints](#participant-endpoints). | It will be up to the DH on how these endpoints are segregated. They may all be on the one domain (so only one certificate required) or could be separated.

### Issued by the Register CA for Data Recipients



Certificate | Function | Notes
-----------|------------------------------------------|------------------------------
|**Client Certificate**| Secures the following:</br>- Consuming Register APIs</br>- Consuming Data Holder APIs
|**Server Certificate(s)**| Certificate is issued to a FQDN.<br/>Secures the following:</br>- CDR Arrangement Revocation endpoint </br>- JWKS endpoint | ADRs may choose to secure their [endpoints](#security-endpoints) with the Register CA issued certificate or a certificate issued by a public CA.
| **Client Certificate** | Secures the following:<ul><li>Consuming Register APIs.<li>Consuming Data Holder APIs.</ul>
markverstege marked this conversation as resolved.
Show resolved Hide resolved
| <span style="white-space: nowrap;">**Server Certificate(s)**</span> | Certificate is issued to a FQDN. | Not currently required by Data Recipients.

### CDR Certificate Authority
[DigiCert](https://www.digicert.com) acts as the certificate authority that issues and manages certificates to CDR participants as directed by the ACCC Register in its capacity as the CDR Registrar.
Expand Down
7 changes: 6 additions & 1 deletion slate/source/includes/security/_transport_security.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,12 @@ All back-channel communication between Data Recipient Software Product and Data
- The presented Client transport certificate MUST be issued by the CDR Certificate Authority (CA). The Server MUST NOT trust Client transport certificates issued by other authorities.
- The presented Server transport certificate MUST be issued by the CDR Certificate Authority (CA). The Client MUST NOT trust Server transport certificates issued by other authorities.

End points for transferring CDR Data that are classified as not requiring authentication do not require the use of **[[MTLS]](#nref-MTLS)**.

```diff
Clarified that public endpoints MUST NOT use 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]](#nref-MTLS)**.


### Holder of Key Mechanism
Expand Down
28 changes: 18 additions & 10 deletions slate/source/includes/security/endpoints/_register.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,18 +32,26 @@ Host: cdr.register

```
<InfoSecBaseUri>/.well-known/openid-configuration
```

```diff
Added clarifying statements for endpoints specified as MTLS and TLS

Added Transaction Security column and clarified descriptions
```

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

| Base URI | DH Brand | ADR Brand | Description
|-----------|------|------|-----------------------------------------------------------------------------------------------|
|**PublicBaseUri**| <i class="icon-check"></i> | | Base URI for the Consumer Data Standard public endpoints. This should encompass all endpoints not requiring authentication.<br>Data Holders designated for the Energy sector are not required to expose energy product reference endpoints via their public base URI and are not required, but **MAY**, provide a redirect to the product reference endpoints hosted by the designated data holder. |
|**ResourceBaseUri**| <i class="icon-check"></i> | | Base URI for the Consumer Data Standard resource endpoints. This should encompass all CDS resource endpoints requiring authentication |
|**InfoSecBaseUri**| <i class="icon-check"></i> | | Base URI for the Consumer Data Standard InfoSec endpoints. This provides ADRs reference to the [OIDC Discovery Endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html) |
|**AdminBaseUri**| <i class="icon-check"></i> | | Base URI for the Consumer Data Standard admin endpoints called by the CDR Register |
|**ExtensionBaseUri**| <i class="icon-check"></i> | | Base URI for the Data Holder extension endpoints to the Consumer Data Standard **(optional)** |
|**RevocationUri**| | <i class="icon-check"></i> | Used for consent withdrawal notification from a Data Holder and is populated in the [SSA](#dynamic-client-registration) |
|**RecipientBaseUri**| | <i class="icon-check"></i> | Base URI for the Consumer Data Standard Data Recipient Software Product endpoints. </br>This should be the base to provide reference to [Data Recipient Endpoints](#cdr-participant-discovery-api_get-data-recipients) |
|**JwksUri**| <i class="icon-check"></i> | <i class="icon-check"></i> | **DH:** Used for client authentication for DH -> DRSP communication and is populated in the [GetDataHolderBrands API](#cdr-participant-discovery-api_get-data-holder-brands)</br> **DR:** Used for client authentication for DRSP -> DH & Register communication and is populated in the [SSA](#dynamic-client-registration) |
Endpoints specified as MTLS **MUST** be configured according to the [Certificate Trust Model](#certificate-trust-model) in the [Certificate Management](#certificate-management) section.
Endpoints specified as TLS **MUST** be configured with a certificate issued by a public CA accepted by major web browsers.

| Base URI | DH Brand | ADR Brand | Transaction Security | Description
|----------|---------|------------|----------------------|-----------------|
|**PublicBaseUri**| <i class="icon-check"></i> | | TLS | Base URI for the Consumer Data Standard public endpoints. This should encompass all endpoints not requiring authentication.<br>Data Holders designated for the Energy sector are not required to expose energy product reference endpoints via their public base URI and are not required, but **MAY**, provide a redirect to the product reference endpoints hosted by the designated data holder. |
|**ResourceBaseUri**| <i class="icon-check"></i> | | MTLS | Base URI for the Consumer Data Standard resource endpoints. This **MUST** encompass all CDS resource endpoints requiring authentication. |
|**InfoSecBaseUri**| <i class="icon-check"></i> | | TLS | Base URI for the [OIDC Discovery endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html) only.<br>Endpoints specified in the Discovery endpoint have the requirements detailed in the [Security Endpoints](#security-endpoints) section. |
|**AdminBaseUri**| <i class="icon-check"></i> | | MTLS | Base URI for the Consumer Data Standard admin endpoints called by the CDR Register. |
|**ExtensionBaseUri**| <i class="icon-check"></i> | | TLS/MTLS | Base URI for the Data Holder extension endpoints to the Consumer Data Standard (optional).<ul><li>TLS: for public endpoints.<li>MTLS: for authenticated endpoints. |
|**RevocationUri**| | <i class="icon-check"></i> | TLS | Used for consent withdrawal notification from a Data Holder and is populated in the [SSA](#dynamic-client-registration). |
|**RecipientBaseUri**| | <i class="icon-check"></i> | TLS | Base URI for the Consumer Data Standard Data Recipient Software Product endpoints. </br>This **MUST** be the base to provide reference to [Data Recipient Endpoints](#cdr-participant-discovery-api_get-data-recipients). |
|**JwksUri**| <i class="icon-check"></i> | <i class="icon-check"></i> | TLS | DH Brand: Used for client authentication for DH -> DRSP communication and is populated in the [Get Data Holder Brands](#cdr-participant-discovery-api_get-data-holder-brands) endpoint. (See: _jwksEndpoint_).</br>ADR Brand: Used for client authentication for DRSP -> DH & Register communication and is populated in the [SSA](#dynamic-client-registration). (See: _jwks_uri_). |
8 changes: 7 additions & 1 deletion slate/source/includes/security/endpoints/_registration.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,13 @@ For more details of these endpoints see the [DCR APIs](#dcr-apis) section.

For additional statements on the operation of these endpoint during client registration see the [Client Registration](#client-registration) section.

| HTTP Verb | Auth Server Support | TLS-MA | HoK | Grant Type | Access Token Scope
```diff
Changed the third column name in the table to align to the Normative References title
- TLS-MA
+ MTLS
```

| HTTP Verb | Auth Server Support | MTLS | HoK | Grant Type | Access Token Scope
|--------------|-------|-------|-------|------|-----------------------------------------------------------------------------
|**POST /register**| Required | <i class="icon-check"></i> | | N/A | None
|**GET /register/{clientID}**| Required | <i class="icon-check"></i> | <i class="icon-check"></i> | Client Credentials | cdr:registration
Expand Down