Comments (6)
Unfortunately the DSB has no information on the specifics of the Register implementation. It is recommended that this question be asked of the Register team on GitHub at https://github.com/cdr-register/register
If an answer is unable to be obtained via that channel then the DSB team would be happy to engage with the ACCC to determine an answer to this query.
from standards-maintenance.
Thanks @CDR-API-Stream, I agree for one part of this query which is why I have asked a linked question there.
On the Standards side however, the question is whether Recipients implementing to the Standards must support both PS256
and ES256
in order to be compliant. As per original question:
More simply is ES256 support mandatory for Data Recipients to implement?
from standards-maintenance.
Apologies, the focus of the query was misunderstood. As the standards do not prescribe any specific algorithm and as the normative references allow for both PS256
and ES256
then a data recipient should support both of these algorithms if they wish to reliably connect to any data holder.
To be clear, however, this is not a mandatory requirement of the CDR standards. Only a practical outcome of the use of OIDC constrained by FAPI R/W. For instance, if all data holders implement PS256
exclusively then a data recipient would not need to support ES256
.
from standards-maintenance.
Apologies, the focus of the query was misunderstood. As the standards do not prescribe any specific algorithm and as the normative references allow for both
PS256
andES256
then a data recipient should support both of these algorithms if they wish to reliably connect to any data holder.To be clear, however, this is not a mandatory requirement of the CDR standards. Only a practical outcome of the use of OIDC constrained by FAPI R/W. For instance, if all data holders implement
PS256
exclusively then a data recipient would not need to supportES256
.
It is impossible for Data Holder to implement and test ES256
as this is only possible if the ACCC Register is an Elliptic Curve CA. Assuming that the ACCC CA is more traditional RSA based the timeline for converting to EC certificates would be measured in years (possibly a decade depending on CA key lifetime).
As per library support outlined at Jwt.io there is a variety of support for these algorithms but requiring support for both decreases the available choices somewhat materially.
In addition the cipher list provided in FAPI-RW and reiterated in the Standards includes EC related combinations.
In order to optimise the pathway for a Recipient to reach CDR compliance I would suggest that explicit guidance be given that at least for the forseeable future only PS256
and a suitable cipher list are required.
from standards-maintenance.
If you would like to propose this change in a change issue with Rationale it will be considered for a future iteration.
from standards-maintenance.
As per above link to CDR Register github, it is impossible to propose a change without information from the government.
from standards-maintenance.
Related Issues (20)
- Retirement date for Get Generic Plan Detail v2 and Get Energy Account Detail v3 HOT 2
- Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType HOT 6
- Update guidance for Banking account rate detail HOT 2
- Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities HOT 3
- AmountString field type impractical for energy tariffs HOT 12
- Set a character limit for resource identifiers
- Clarify selection of Trusted Adviser in the CX Guidelines HOT 9
- Maintenance Iteration 20 Holistic Feedback HOT 7
- Adopt BCP 195 for TLS ciphers HOT 2
- Inconsistent JARM error responses HOT 2
- Weaken JARM Encryption Requirements for ADRs HOT 1
- Supporting HTTP Status 429 passthrough from Secondary Data Holder HOT 2
- Specify units of currency to be used for the AmountString field type HOT 5
- EnergyPlanTariffPeriod - cater for plans with no dailySupplyCharge HOT 5
- Clarify Transaction Security requirements
- Get Metrics V5 error metrics documentation HOT 1
- A status of POSTED should indicate the final update for a transaction
- Addition of LVR in the enumerated values list for constraintType HOT 1
- Guidance in the standards for a posting date/time where no time is stored HOT 9
- Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-maintenance.