Remove deprecated Register scope detail

[nils-work]

Description

The Admin & Registration section contains details of scopes for Data Holder Admin and DCR endpoints, and Register endpoints used by Data Recipients.

Intention and Value of Change

To remove details of the deprecated Register scope: cdr-register:bank:read

Area Affected

• Admin & Registration section

Change Proposed

Replace the existing rows:

Scope Name	Scope ID	Description
Bank Participant Data	cdr-register:bank:read	This scope would allow Data Recipients and Data Holders access to participant metadata in the banking sector, held by the CDR Register. This scope is valid for the following endpoint versions: GetDataHolderBrands V1 GetSoftwareStatementAssertion V2 This scope is replaced by cdr-register:read for newer versions of these endpoints.
Participant Data	cdr-register:read	This scope would allow Data Recipients and Data Holders access to participant metadata held by the CDR Register. Replaces cdr-register:bank:read for the following endpoint versions: GetDataHolderBrands V2 GetSoftwareStatementAssertion V3

with only a single row for the current valid scope:

Scope Name	Scope ID	Description
Participant Data	cdr-register:read	This scope allows Data Recipients to get a Software Statement Assertion and access to Data Holder metadata held by the CDR Register.

[nils-work]

The Non-normative Examples for the Register endpoints could also be updated:

Non-Normative Example - Data Recipient Software Product requests CDR Register Access Token

POST /token HTTP/1.1
- Host: cdr.register
+ Host: secure.api.cdr.gov.au

- scope=cdr-register%3Abank%3Aread
+ scope=cdr-register%3Aread

- "aud": "https://cdr.register/idp/connect/token",
+ "aud": "https://secure.api.cdr.gov.au/idp/connect/token",

- "scope": "cdr-register:bank:read openid"
+ "scope": "cdr-register:read openid"

and

Retrieve CDR Register OIDC Discovery Endpoint

- GET /.well-known/openid-configuration HTTP/1.1
+ GET /idp/.well-known/openid-configuration HTTP/1.1

- Host: cdr.register
+ Host: api.cdr.gov.au

- "issuer": "https://cdr.register/idp",
+ "issuer": "https://secure.api.cdr.gov.au/idp",

- "jwks_uri": "https://cdr.register/idp/.well-known/openid-configuration/jwks",
+ "jwks_uri": "https://api.cdr.gov.au/idp/.well-known/openid-configuration/jwks",

- "token_endpoint": "https://cdr.register/idp/connect/token",
+ "token_endpoint": "https://secure.api.cdr.gov.au/idp/connect/token",

- "scopes_supported": ["cdr-register:bank:read"],
+ "scopes_supported": ["cdr-register:read"],

- "scope": "cdr-register:bank:read openid"
+ "scope": "cdr-register:read openid"

and references to:
<brand id> OR <software product id>

could be reviewed in relation to the following statement in Data Recipients calling the CDR Register:

Data Recipient Brand ID and Software Product ID are both currently supported as client identifiers for client authentication. Data Recipient Brand ID as a client identifier will be deprecated in the future and is currently retained for backwards compatibility

[perlboy]

They are non-normative but the suggested update includes a host update to something "real", not sure if that's intentional but if it is it's incorrect as the discovery document is at /idp/.well-known/openid-configuration not /.well-known/openid-configuration.

Also, since we're on the topic, the Register is in violation of RFC8615 based on the following statement: Well-known URIs are rooted in the top of the path's hierarchy; they are not well-known by definition in other parts of the path. For example, "/.well-known/example" is a well-known URI, whereas "/foo/.well-known/example" is not.

[nils-work]

Thanks @perlboy, I've marked that line to be updated as well (ref).

For reference, changes to the server values in the Register endpoint spec have also been staged for the next release.

Unless I misunderstand, as the Register well-known is effectively being provided out of band and the issuer has a path component, according to OIDC that can be valid? I understand some Data Holders have similar patterns.

[perlboy]

Unless I misunderstand, as the Register well-known is effectively being provided out of band and the issuer has a path component, according to OIDC that can be valid? I understand some Data Holders have similar patterns.

It was more a reference to the well-known RFC spec which bans it (and OpenID overrides when discovered via WebFinger). In the ACCC case:

1. This clause would only applicable if it was discovered via WebFinger (which it wasn't), hence RFC8615 is more authoritative
2. Register is spec non-compliant here because their issuer being the MTLS endpoint (https://secure.api.cdr.gov.au/idp) not matching the issuer base uri for the discovery document (https://api.cdr.gov.au/idp).

[nils-work]

Related to example changes, see #682 - Spec alignment - OpenID Provider Configuration and issuer value.