-
Notifications
You must be signed in to change notification settings - Fork 5
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
Dynamic registration of accredited data recipients #63
Comments
Hi James |
NAB is currently concerned with the proposed registration solution and the ramifications it could create. Whilst we understand that the ACCC is currently working on the solution design for the Directory, the following aspects of registration need further consideration:
To reduce the level of complexity and increase support for standard protocols, NAB is supportive of the implementation of Dynamic Registration from day 1. Depending on the ACCC's requirements (e.g. a centralised copy and control over participant's metadata), we believe there are other technical ways to address it, as for example, upon DR registration with the ACCC its metadata is stored in the directory and they are issued with the "software statement" signed by the ACCC that reflects that metadata. The DRs then use the signed software statement to register with the DH of their choice using dynamic registration endpoint. This solution adheres to the OIDC standards and has been adopted in the UK. Implementing dynamic registration endpoint on the DH side will be less complex then implementing the synchronisation polling against the directory. Also, the responsibility for metadata registration relies upon the DR. If the freshness of the metadata in the directory and on the DH side is an issue, a variant of the above scheme is that directory itself implements the registration with DHs on behalf of the DRs, so in fact it acts as a caching proxy and can ensure that all instances of the metadata across directory and all DHs are in sync with real time status of synchronisation being held centrally within the directory. |
Westpac supports the comments made by NAB on this issue. Abandonment of an already supported and existing standard is likely to delay implementation and increase expense for both Data Holders and Data Recipients who have opted to purchase, configure and use tools from software vendors in relevant parts of their implementations. If it is not possible to have dynamic registration in the short term, then consideration should be given to the option of manually registering clients for an initial period and adding dynamic client registration at a later date. A non-standards based model involving implicit trust of an external credential store rather than a trust framework also needs careful consideration of the increased risks from a security perspective. Use of this approach would also require significant deviations from the normative references currently used in the InfoSec standards. Those normative references assume client registration as fundamental part of their design. In particular, [OAUTH2] and [OIDC] make explicit reference to a litany of parameters which must be registered with the provider and validated against this registration in steps of the flow. At a minimum, the metadata store approach would require:
|
In reference to the comment from NAB:
This is effectively what is proposed. This is to provide the ACCC with control over the software metadata but also the status of the Data Recipient. This is the same driver for the inclusion of a CDR specific CA as it provides the ability to revoke certificates centrally. With regard to keeping the cache in sync, there will be an accepted lag in the transfer of updates to the cache for most scenarios with a mechanism to do a force refresh if a critical change (like the revocation of accreditation for a recipient) occurs. More detail on this mechanism must, of course, be provided. -JB- |
After discussions with the ACCC Directory development team the current hypothesis for v1 is that all information required for a data holder to authenticate and communicate with an accredited data recipient (and vice versa) will be held within the meta data store in the Directory. This would mean that dynamic registration mechanisms would not be included in the standards.
If anyone has any thoughts or concerns on this position then feedback would be welcome.
The text was updated successfully, but these errors were encountered: