Feedback 25 - Dynamic Client Registration

[CDR-Register-Stream]

This thread has been created to allow for feedback on Dynamic Client Registration within the CDR Ecosystem.

Details can be found at: https://cdr-register.github.io/register/#dynamic-client-registration

All feedback is welcome.

[anzbankau]

Some queries based on the latest registry design (both directly and indirectly related to DCR):

• For the Dynamic Client Registration APIs - could there be samples or further information provided on what fields are expected to be required/supported.
• What is the domain under which the DCR API need to be deployed and will MTLS be used? Presumably InfoSec, and yes?
• For GET, PUT and DELETE of the Dynamic Client Registration API - the Grant Type is specified as Client Credentials. There is a link to further documentation (https://cdr-register.github.io/register/#client-authentication), but this doesn't seem to cover DCR operations. Additionally, what scope is required to call these APIs?
• In UK the DCR Post request is signed by the Data Recipient (TPP) - Is this the expectation for CDR?
• Is there still a recipient level accreditation status that Data Holders will need to obtain and assess – the current APIs available only have a product status available (https://cdr-register.github.io/register/#getsoftwareproducts). Additionally is the software product status anticipated to align to https://cdr-register.github.io/register/#participant-statuses - currently the values are 'Active', 'Inactive', 'Removed'.
• Is the expectation for checking product status during client registration that:
  • Data recipient would attempt to register and provide their SSA
  • Data holder would validate SSA signature with ACCC JWKS
  • Data holder would make a call to Get Software Products on the ACCC Register to check the product status.
• Will the JWKS of the recipient/holder/register be public or secured with MTLS?

[NationalAustraliaBank]

NAB has the following feedback across the sections of the draft CDR Register Client Registration documentation.

Digital Signing Algorithm

The supported software statement signing algorithms must align with what is supported under the CDS. ES256 has been removed from the CDS InfoSec profile (https://github.com/ConsumerDataStandardsAustralia/infosec/issues/66) and must not be used to sign the software statement. PS256 is available under the FAPI profile.

SSA Definition

1. The jwks_endpoint metadata value to be named as jwks_uri .

2. Recommend that the values supported under the software_roles metadata value aligns with the proposed entity, brand, software product model. I.e. Data Recipient Software Product instead of Data Recipient .

3. iss_tos metadata value:

   • What is the intended use for this field? And would this URI be presented to the end user during authorisation? If so, when the CDR Register wants to change their CDR terms of service URI, then all data recipients would have to update their software product's client registration. The CDR Register's terms of service URI metadata must be managed independently of client metadata and must not be included in the client's software statement.

   • If this value remains, then suffix with _uri .

4. org_contacts metadata value:

   • As the ACCC advised that this object can be different per software product, then adopt the existing open standards contacts metadata value into the software statement, which is intended to be able to be displayed during the consent authorisation flow.

   • To publish contact points to support business and operational communication between Data Recipients and Data Holders, these contact points must instead be made available in the CDR Register portal rather than having them stored in the authorisation server directory, which could get out of date given that it does not impact the technical solution.

   • The Get Data Holder Brands API, does not contain data holder contact information, so we expect that Data Recipients would be able to find these out in the CDR Register portal as previously described.

Logos

Logos will be incorporated within the SSA to ensure there is consistency between the logos published on the Public Register and those passed to Data Holders as part of Registration

Clarifying that this refers to the logo URI, not the logo content itself.

Software Product JWKS

JWKS will be decentralised and the URI described in the OIDC Discovery endpoint

The JWKS URI is also in the software statement (jwks_endpoint / jwks_uri) for the software product, as well as the "token revocation" URI (revocation_uri). With the above statement, it indicates that Data Recipient's will also provide an OIDC Discovery compliant endpoint. Is that correct? Is the inclusion of both locations to ensure consistency?

Registration Request using JWT

1. The token_endpoint_auth_signing_method metadata value to be named as token_endpoint_auth_method .
2. Will the valid values for application_type values align to OIDC Dynamic Client Registration 1.0 values (native, web)?

Registration API Endpoints

1. Clarifying that the resource URI for the Registration API endpoints will be /register & /register/{client_id} .
2. Will the authentication of the /register endpoints (where applicable) follow the private_key_jwt client authentication method?

[WestpacOpenBanking]

Westpac supports the decision to adopt dynamic client registration .We have the following questions and comments in relation to the draft specification:

Client Registration

• We assume ‘Authorisation Server Support’ being required for the client registration request (POST) only means that Data Holders must implement support for that endpoint and not that that the client registration request endpoint requires an initial access token as allowed for in (RFC 7592 and [OIDC-DR]). We suggest the addition of explanatory text under the table to this effect.

• Further to the above, we suggest explicitly outlining the authentication, authorisation and validation steps that must be performed on the POST /register endpoint.
• We suggest that a software_id claim is added as an optional part of the registration request, and that it must match the software_id client metadata in software_statement if present. This aligns the software_id with the definition in RFC7591.
• We suggest that the validations that must be performed before a registration request is accepted are made explicit. We suggest the following validations are required:
  • That software_statement is present.
  • That the elements in both the registration request and software_statement are valid.
  • That the software_statement has not expired.
  • That software_statement has a valid ACCC signature. This must be checked against the register’s JWKS endpoint (see question below).
  • That the signature in the registration request JWT is validated against the jwks_endpoint specified in software_statement.
  • That redirect_uris in the registration request (see below) is required to be a subset of the redirect_uris.
  • That if software_id is present in the registration request (see below) is required to be equal to the software_id in software_statement.
• It would be helpful to clearly articulate all fields to be returned in the event of successful client creation. Our current understanding of the intent of the specification and of RFC7591 is that client_id, client_id_issued_at, an unmodified copy of the software_statement from the request, all fields from software_statement and all fields present in the registration request JWT. We assume that client_secret is not required due to the use of private_key_jwt throughout the system.

Client Authentication

• The specification is currently ambiguous with respect to the method of client authentication for read, update and delete requests. This is because the referenced section 9 of [OIDC] in the Client Authentication section describe authentication methods valid for a token endpoint only. Westpac assumes that to perform an update the client software will first obtain an access token from the token endpoint using the client_id issued to it during the registration request. The client assertion for this request would be signed using a valid key and this would be verified using the client’s JWKS endpoint. Once an access token is obtained it can be used to access the GET /register, PUT /register and DELETE /register endpoints. We note that this is similar to the UK specification but differs from RFC 7592 and we support this deviation. As distinct from the UK specification, we suggest that the access token request lists “register” as the requested scope rather than no scope.
• Since the above differs from RFC 7592 we request confirmation that our interpretation is correct.

Transport Security

• The specification does not specify the method of transport security for client registration or which certificates should be used.
• Further detail as to the validations that must be performed on client certificates is also needed. See this example from the UK specification.

Other comments and questions

• Will the ACCC be hosting a JWKS endpoint for the purposes of validating software statement signatures (see validations above)? Where will the URI of this endpoint be published?
• For the PUT, GET, DELETE operations we note that the method of obtaining the registration_client_uri differs from RFC7592 but is aligned with the UK Open Banking approach and support this decision.

[anzbankau]

• If the Data Recipient sends additional claims (beyond CDR specification) should the request be rejected or we just don’t send them back? Our recommendation would be we don’t send the claims back in UserInfo.
• For the DCR APIs, could examples please be provided for the GET and PUT end points.
• Could swaggers for all the register end point please be provided.
• There are no specifications around what should be the headers in the register end points. Could this please be specified?
• In the DCR POST request there are 2 fields which are specified as String where we believe they should be an array of strings (grant_types and response_types)
  • For example: "grant_types":"[ authorization_code, refresh_token, urn:ietf:params:oauth:grant-type:jwtbearer ]"

[anzbankau]

grant-type:jwt-bearer appears to have a small typo in the documentation.

As of now the design has:

"grant_types":"[
      authorization_code,
      refresh_token,
      urn:ietf:params:oauth:grant-type:jwtbearer
   ]"

While as per the standard (https://tools.ietf.org/html/rfc7523#page-10) it should be

"grant_types":"[
      authorization_code,
      refresh_token,
      urn:ietf:params:oauth:grant-type:jwt-bearer
   ]"

[fahadbinrahat]

• It appears that there is no requirement to check software application status during DCR flow.

• it also appears that there is no requirement to check ADR level status (as there is no visibility of this status to data holder via proposed metadata data structure.)

In other words DH will rely on CDR register's issued SSA and trust that these checks have been done by CDR register prior to issuing SSA. Moreover, it is trusted that the 30 minutes lifetime window of downloaded SSA is smaller enough for a software product status change which is why there is no requirement to check software application status against metadata cache on DH side.

Can these be confirmed please?

[imesh94]

• Currently is there a way to obtain a signed SSA to test an implementation? Is there a JWKS endpoint to verify the SSA?
• When can we expect the swagger files for the registration endpoints to be released?

[imesh94]

Under the registration response section [1] "redirect_uris" property seems to be repeated in the example response. [1] -https://cdr-register.github.io/register/#registration-response

[commbankoss]

In a recent revision to the Registry design, Data Receiver Discovery API has been reduced to Status API only, with all Data Receiver metadata moved to the SSA.

• Commonwealth Bank recommends separating security and business data. Security data should be carried over in the SSA and business data should be available via Data Receiver Discovery API. This will allow security data to be consumed by security infrastructure (authorisation server) and business metadata to be consumed by business applications (e.g. consent dashboard using software product logo, url, product name and product description).

• This will also minimise unnecessary SSA updates for ADRs for business metadata that can be updated via portal without re-registration.

[fahadbinrahat]

Is it expected that GET /register/{clientID} returns a 200 response code with client registration details while ADR Software Product Status is "inactive" or "revoked".

The responsibility of Data Holder in relation to participants statuses defined on this link does not talk about DCR flows explicitly.

It appears that a suspended/removed ADR can still continue to retrieve previously registered software's client registration details from data holders successfully. It looks like it is similar to UK specs as mentioned on this link

Can this be confirmed if this is expected behaviour?

[fahadbinrahat]

Noticed that Create Registration and Modify Registration flow diagrams on this link have been changed on 16th October as a result of this commit in the repository. And this change is not called out in change log section of the page.

Following changes are made:-

1) A new alternative flow is introduced "IF JWKS cache has expired" 2) "Get Software Product Metadata" call from DH to Register is introduced 3) A check on Software Product status is introduced

Kindly update the change log for traceability purposes.

Edit:- A question on above change, would it make any difference if software product status check is done before validating SSA?

[fahadbinrahat]

What behaviour is expected from Create Registration endpoint when an ADR submits a registration request (for a software product that is already registered i.e. client was created previously as a result of an old registration request) ?

The RFC7591 provides a duplicate detection method using software_version element in SSA. But specified SSA does not include this element.

Should this element be part of SSA or an ADR is allowed to create multiple clients (the later option introduces complications. please refer security consideration on this link).

[CDR-Register-Stream]

@fahadbinrahat The SSA definition is provided here. The software_id is the primary identifier for a registration. No duplication of registrations is allowed.

The sequence diagrams have been cleaned up to no longer require the DH to check the status of the software product prior to registration. To minimise "invalid" registrations occurring, SSAs will only be issued for ACTIVE software products.

[ttranatping]

Does a DCRM GET response require the software_statement?

The OAuth specifications for POST state:

If a software statement was used as part of the registration, its value MUST be returned unmodified in the response along with other metadata using the "software_statement" member name. https://tools.ietf.org/html/rfc7591#section-3.2.1

• Note: There are no references to software_statement in rfc7592 (DCRM) as the software_statement requirement for PUT is unique to Open Banking / CDR.
• DCRM GET requests do not provide a software_statement value, so the unmodified value for GET is arguably null/empty according to OAuth.

CDR does not separate the expected DCR response for the various requests and has software_statement as a required response property for POST/PUT/GET (see here). The software_statement claim is provided for both POST and PUT requests, so it must be returned. However, software_statement is not provided through a GET request.

Question - Should a DCRM GET request return the software_statement property? This requirement will have the banks store the latest successful software_statement used during POST/PUT.

Edit: We also found that in OpenBanking UK, they have a requirement for software_statement to be present in both the request and the response. We see this to be an inconsistency as the GET request does not contain a software_statement, and question whether it then should be in the response.

[CDR-Register-Stream]

@ttranatping thank you for your query.

A few things to note:

1. RFC 7592 does not specify PUT or GET requests as part of the specification
2. PUT and GET specifications in our design are built on top of the work done by Open Banking UK.
3. POST, PUT and GET return the Registration Properties schema. This does include the SSA

There have been some discussions internally on the benefits of persisting the SSA as part of the registration. One benefit is allowing DHs and ADRs traceability on the registration if any of the fields were modified as part of the registration flow.

Therefore, to summarise, as specified in the Dynamic Client Registration API section of the CDR Register design, GET, POST and PUT requests MUST return the SSA as part of the response.