[ARCHIVE] URI structures

Archived 2023.09.18. See CDS, URI Structure

Question

URI standards are defined in CDS URI structure. These standards are applicable for the resource server. Are there URI structure standards defined for the security profile endpoints?

Answer

Yes. The structure for these end points is defined by the normative standards. The structure is relatively open with the end points being defined by the DH  (Data Holder) in the OIDD (OpenID Connect Discovery) compliant discovery document. See:

• CDS Security Endpoints
• Section 3 and 4 of the OpenID Connect Discovery standards (OIDD)

Question

Standards allow different data holder paths for authenticated and unauthenticated endpoints. Can the data holders have different paths for security profile endpoints and banking endpoints?

Answer

Yes.  The register specifically allows for multiple base URIs for multiple purposes.  See CDS Security Endpoints, Participant Endpoints.  This includes a specific base URI for the Information Security profile end points.  Note that you can reuse the base path for multiple entries but this is sometimes difficult due to the various TLS  configurations that are required.

Question

Below are some examples based on the various combinations. Does this align with standards and best practices? The URL components that are base paths are bolded in the URLs below.

Unauthenticated Resource URL:
https://openbanking.api.bankname.com.au/cds-au/v1/banking/products

Authenticated Resource URL:
https://openbanking-secure.api.bankname.com.au/cds-au/v1/banking/account

Unauthenticated security profile URL:
https://openbankingidp.api.bankname.com.au/.well-known/openid-configuration

Authenticated security profile URL :
https://openbankingidp-secure.api.bankname.com.au/arrangements/revoke

Answer

The structures described above are aligned to what was intended and also compliant with the standards. No best practice has been defined. 

Question

The Standards have three baseURIs clearly articulating their purpose ( PublicBaseUri, ResourceBaseUri and InfoSecBaseUri ). Should there be a separate baseURI (similar to the other three) representing the authenticated InfosecBase URI?

This way it is explicit and consistent with the resources: Public & Authenticated

Answer

The InfosecBaseUri points to the OIDC Provider Configuration Endpoint. From here, reference to the assorted infosec endpoints such as token, authorize etc can be derived. How these endpoints are split between domains is an implementation issue for data holders to determine and they can request ACCC CA issued certificates as required.

Adding these references to the CDR Register would be redundant and risk synchronisation issues as there would then be two discovery points.