Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 9th of June 2022

Jump to bottom
elizabetharnold edited this page Jun 9, 2022 · 6 revisions

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: [email protected]

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

  • 5 min will be allowed for participants to join the call.

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may [email protected] should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

Updates

Type Topic Update
Standards Version 1.17.0 Published Link to change log here
Maintenance DSB Maintenance Iteration 11: Agenda & Meeting Notes on 25th of May 2022 Link to the agenda and minutes
Maintenance Additional session on Tuesday the 14th of June 2022 Focused on Energy items for Maintenance Iteration 11
Maintenance Final meeting on Wednesday the 22nd of June 2022 To receive an invitation: reach out to [email protected]
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 6th of April 2022 View in browser here
DSB Newsletter 3rd of June 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their stream of work

Organisation Stream Member
ACCC CDR Register Emma Harvey
ACCC CTS Preeti Patel
DSB CX Standards Michael Palmyre
DSB Technical Standards - Energy & MI11 Hemang Rathod
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

Answer provided

Ticket # Question Answer
567 Seeking your guidance in determining customer eligibility in Consent flow. A Customer may have 3 types of relationships (profiles) with a bank: individual customer, sole trader (held by a business registered in a name of one person only), be a member in partnership. When a customer who has such profiles logs in to Consent flow, they would need to select which profile they like to proceed with before being able to see eligible accounts for data sharing. For a customer who is an individual and a sole trader business owner, in a scenario when this customer has active account for personal savings as an individual, and a closed account for Business Term Deposit as a sole trader, will this closed Business Term Deposit account be considered in scope for data sharing, or ineligible as this customer has no more active accounts as a sole trader with the bank? To rephrase, is eligibility requirement to have at least one open account with a data holder to be determined based on personal & business profiles combined, or separately for each profile? Please see our guidance on Digital channels and the eligibility of CDR consumers.
1289 Have a question related to revocation of once-off consent with sharing_duration = 0.
In the above case since sharing_duration=0 we assume the cdr_arrangement_id(consent) is immediately expired upon its creation/issue.
Considering the above
- Would this cdr_arrangement_id show up in DH consent dash board. Per link(https://cdr-support.zendesk.com/hc/en-us/articles/360004430855-Displaying-one-off-consents-on-Data-Holder-dashboard) it shows up as expired. In this case can the consumer initiate a Withdrawal on this cdr_arrangement_id?
- Also can DR still be able to call DH revoke end point with this cdr_arrangement_id?		 - [Question] Would this cdr_arrangement_id show up in DH consent dash board. In this case can the consumer initiate a Withdrawal on this cdr_arrangement_id?
[Answer] One-time consent with a sharing_duration=0 means the DH only issues an access token and no refresh token is issued. In this case, the consent remains access for the duration of the access token (this is DH dependent but must be between 2 and 10 minutes). There is no withdrawal mechanism required. Whilst a consumer could initiate withdrawal on the ADR side, practically speaking it is of limited benefit. An ADR may offer this functionality however they should verify if the access token has expired yet or not. If the ADR knows the consent has expired it shouldn't be offering a withdrawal mechanism.
- [Question] Also can DR still be able to call DH revoke end point with this cdr_arrangement_id?
[Answer] Yes however the arrangement would already have been expired and the expected behaviour is that the DH will return an error.
1359 I can see that FAPI is being implemented in 3 phases. If we are late delivering phase 2 or 3 for example, will we still be able to function using phase 1 after phase 2 is due? What could the consequences be if we are late on phase 2 or 3? What could the consequences be if we are late on phase 2 or 3?
We encourage stakeholders to seek their own legal advice regarding compliance with CDR obligations.
The CDR Rules require binding data standards to be made for certain CDR processes including, authentication of CDR consumers and seeking authorisations to disclose CDR data in response to consumer data requests. Additionally the CDR Rules require certain things to be done in accordance with the data standards, including, asking a CDR consumer to authorise the disclosure of any requested required consumer data.
Non-compliance with the CDR Rules and data standards will be considered in line with the ACCC/OAIC Compliance and Enforcement Policy for the Consumer Data Right.
1444 Part 1 Clarification regarding FAPI 1.0 advanced profile roll-out
This is regarding the rollout of FAPI 1.0 related changes (Decision Proposal 209). For phase 1, the decision proposal mentions that it could be rolled out as soon as possible even before the obligation date. But it doesn't mention it for phase 2 or 3. Does this mean we cannot rollout the phase 2 changes before the obligation date?
Also with phase 2 there are changes that affect ADRs as well and hence may cause problems when rolled out early.
[Question] For phase 1, the decision proposal mentions that it could be rolled out as soon as possible even before the obligation date. But it doesn't mention it for phase 2 or 3. Does this mean we cannot rollout the phase 2 changes before the obligation date?
[Answer] The Baseline Security Provisions sections details the additive requirements. The intention is to progressively phase in support so ADRs can also migrate. Particularly, Phase 3 permits the retirement of OIDC Hybrid Flow. This wouldn't be possible until the Phase 3 milestone otherwise it would break existing ADR software products. Are there particular aspects you are looking to support in either Phase 2 or Phase 3 that you want to go live with earlier?
1444 Part 2 Here are some of the concerns we found that may affect the ADRs if phase 2 is released before the ADRs are ready.
Nbf claim in the request object is mandatory
PAR is mandatory
PKCE mandatory ( for all new apps created from DCR)
As mentioned in the previous response, our understanding is that the phase 2 and 3 changes should be released close to the obligation date. Please advise if that's not the case.		 PKCE is mandatory but ADRs have until Phase 2 to commence this implementation which is the sending of the code challenge and code verifier values.
PAR is mandatory from Phase 2. Community feedback indicated that most ADRs already support PAR exclusively for staging authorisation requests. Given PAR requirements have been in place since November 2020, moving to PAR only lodgement for authorisation requests will improve the ecosystem's security posture and be a small change for ADRs.
ADRs can and should be providing the "nbf" claim now. They have until July 4th (Phase 1) to uplift their software products to send it in accordance with FAPI 1.0 Final Advanced requirements. From that data Data Holders must reject invalid "nbf" values and invalid "exp" values in relation to the "nbf".
1444 Part 3 Just one concern regarding the last sentence that Data Holders must reject invalid nbf values. The specification and DP 209 state that it's only mandatory for Data Holders to validate nbf only from phase 2. That's correct.
1463 AEMO APIs Vs EnergyAPI - Clarification required for closed account - tokenised service point id
As per AEMO API specification (V0.3), AEMO will return the service point information (Get Service Point API) if Retailer (i.e Data Holder) is the current FRMP (i.e having billing rights currently).
In EnergyAPI list (Get Service Points – Consumer Data Standards (consumerdatastandardsaustralia.github.io), Get Service Point API is expected to return the Tokenised Service Point ID which then shall be used by ADR in APIs like Get Usage for Service Point or Get Usage for Specific Service Points (i .e specifying the tokenised service point ID in the request).
Tokenised Service Point ID will be created by Data Holder but other Service point information (classification, status, jurisdiction code, isGenerator etc.,) in the standards needs to be returned by AEMO.
Retailer (i.e Data holder) may or may not be the current FRMP for a Closed Account. If AEMO is not returning the Service point information for a closed account (if DH is not the current FRMP of NMI) then ADR cannot receive token service point ID from retailer/DH for closed account. So they will not be able to use usage APIs that has Service Point ID specified in the request.
Can you please advise the expected outcome in this scenario?		 There are a few points to highlight that may help answer your question:
As per the rules, usage data is classified as required data for closed accounts, not standing data (i.e. service point data).
Apart from Get Service Point API, the Retailer would also create/issue service point id's via the Get Energy Accounts API. This would allow the ADR to then use the service point id to request either usage data or billing data for closed accounts.
1485 Self-signed JWT for Arrangement Revocation
On the self-signed JWT for Arrangement Revocation from Data holder to Data Recipient -
1. Is data recipient expected to fetch the public keys from jwks endpoint already hosted by the data holder?
2. Which signing algorithms are permitted? - PS256 or ES256?
We are confused by the non-normative example in the standards where it specifies HS256
as below -
{
"typ": "JWT",
"alg": "HS256",
"kid":"12456"
}
{
"cdr_arrangement_id": "5a1bf696-ee03-408b-b315-97955415d1f0"
}		 ** Question 1.** Is data recipient expected to fetch the public keys from jwks endpoint already hosted by the data holder?
Answer 1. That is correct.
Question 2. Which signing algorithms are permitted? - PS256 or ES256? We are confused by the non-normative example in the standards where it specifies HS256
Answer 2. In v1.17.0 we have corrected the non-normative example. It now shows "PS256".
1486 Regarding ‘controlledLoad’ (EnergyPlanControlledLoad) segment within Get Energy Account Detail API
The current ‘controlledLoad’ (EnergyPlanControlledLoad) segment within Get Energy Account Detail API, is an object and not an array structure and in this instance only one set of controlled load detail can be passed to the structure;
However, there can be few instances where a customer has two controlledLoad tariffs applicable say e.g., both Tariff 31 and 33 rates applicable to customer’s account
Is it possible to update same or provide feasibility for passing multiple ‘controlledLoad’ tariff details within this segment (as applicable):
CURRENT SEGMENT REPRESETATION:
{
"displayName": "string",
"description": "string",
"dailyCharge": "string",
"period": "string",
"rates": [
{
"unitPrice": "string",
"volume": 0
}
]
}		 Change request 472 is looking at various changes required to the controlled load schema, including making it an array. It is part of the current maintenance iteration 11. This comment outlines the latest solution option.
I recommend providing any feedback you may have on the CR thread directly so that rest of the community can review/provide their thoughts.
1487 Regarding 'displayName' field, in Get Concessions CDR API
Is this correct understanding that - in the 'displayName' field (of GET CONCESSIONS api) the "Concession or Rebate NAME" is required to be populated.
i.e. "name of concession or Rebate"
(e.g. Annual Electricity Concession/ Energy Accounts Payment Assistance Scheme/ Medical Cooling and Heating Rebate/ Service to Property Charge Concession etc.)
rather than "Concession CARD name/type"
(i.e. Pensioner Concession Card (PCC) / Health Care Card (HCC) / Department of Veterans' Affairs (DVA) etc.).		 The displayName field is at the discretion of the data holder and is intended to provide a meaningful name that the consumer can understand. What you have suggested (name of concession or rebate) makes sense as the card name/type would not be that meaningful.
See similar question/answer in banking -https://cdr-support.zendesk.com/hc/en-us/articles/900005430063-BankingAccount-nickname-productName-and-displayName-fields.
1493 Regarding field "additionalValue" in GET CONCESSIONS API (Reference: Iteration 10 # 476)
In the proposed structure (Iteration 10#476), for GET CONCESSIONS API; where field "type” = "VARIABLE", then field "additionalValue" become mandatory to be populated:
Qs. field "additionalValue" (in the above instance) is expected to be populate with:
a. the ‘rebate/concession amount’ of applied to the customer’s account (e.g., 'Energy Accounts Payment Assistance (EAPA) voucher' applied amount , 'Owner Onus amount of rebate amount being claimed etc.)
OR
b. the ‘calculation logic’ (i.e., formula or criteria utilised to calculate the rebate/concession)		 The agreed structure for get concessions API resulting from CR 476 does not include the additionalValue field. It now contains additionalInfo and additionalInfoUri fields which allow the DH to provide descriptive text and links to external sources with additional information.
1496 Do Data Holders need to enforce aud = resource path?
From July 31st 2022, Data Recipients MUST verify the audience is the "resource path" and MUST NOT accept the audience of Recipient Base URI. Is it required for Data Holder to (MUST) verify the audience is the "resource path" and MUST NOT accept the audience of Recipient Base URI by 31st Jul 2022?		 this change is in respect to the Data Recipient hosted endpoint. That being the ADR's CDR Arrangement Revocation Endpoint. From July 31, Data Holders must authenticate against the ADR endpoint by setting the audience value to the "Resource Path" when using Self-Signed JWT client authentication. Note that Data Recipients call Data Holders using Private Key JWT client authentication not Self-Signed JWT client authentication.
1506 Payee PayID Types
For Payee PayID, there are 4 types provided to categorise all PAYID's (Phone, Email, ABN and Org ID) but NPP payments can also be sent via Bsb and Account numbers which still return a PayID response BUT do not meet any of the 4 types provided within the rules. in this situation should we return an empty response in 'type' field?
"nickname": " ",
"description": "Mawson Lakes Mazda",
"type":
"DOMESTIC",
"creationDate": "2022-03-29T00:00:00",
"payeeUType": "domestic",
"domestic": {
"payeeAccountUType": "payId",
"payId": {
"name": "Mawson Lakes Mazda",
"identifier": "085-458773186118",
"type": "None"		 a PayID is one of a phone number, email address or registered business number and it acts as an alias to the BSB and Account Number. The BSB/Account Number is not itself a PayID.
BSB/Account number is represented as a BankingDomesticPayeeAccount typed payee and the payeeAccountUType would be "account".
1510 When a Nominated Representative gives consent, on behalf of a business account, should the tokens issued during authentication relate to the business account, or the Nominated Representative user? For non-individual consumers the PII claims (e.g. sub, given_name, family_name) are related to the authenticated end user (the nominated representative). The Customer API data is related to the non-individual consumer (the business) and the resource IDs are bound to the non-individual consumer (the business) not the authenticated user (the nominated representative). In otherwords, the accountId for account 12345 should be the same regardless of the nominated representative establishing consent on behalf of the non-individual consumer. ID Permanence should still follow the other standards in accordance to the CDR Federation section.
1512 FAPI 1.0 July 2022 Release
For Jul, 2022 release PKCE support is optional. Our vendor product supports PKCE OOTB however, we are not ready for requests related to Authorization Code flow.
What should be the DH behaviour if we do not publish the metadata for code_challenge_supported_methods? Will ADRs still invoke authorization code flow using PKCE claims? If yes, can Data holders modify the authorize URL to remove the optional claims (e.g. code, code_verifier) in order to serve the request and not process/reject it using PKCE as we will not be ready with PAR support for requests by Sep 2022.		 this issue is being discussed in the current Maintenance Iteration: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/500
The expectation is that Data Holders do not reject clients that send the code_challenge and code_challenge_method (i.e. they ignore them) in the request object.
The Data Holder advertises that they do not support PKCE through the absence of the code_challenge_methods_supported parameter in their OpenID discovery document.
1513 User Info API for Nominated Representatives
In regards to the User Info API in the OAuth Specifications (that provides information about the user establishing the consent), this oAUth API mostly deals mostly with the consumer use case. For the obligations related to business consumers, for a business account user consenting to share business account information that they are a nominated representative for, should User Info represent the business account info or the nominated representative?		 the UserInfo response relates to the authenticated end user. For individual consumers this is currently the consumer. For non-individual consumers this will be the data of the nominated representative.
1517 Here are some questions where we need clarifications & Confirmation
1. In one of the response to another ticket (1307- https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Meeting-Notes-%7C-5th-of-May-2022), the following point was mentioned "This is independent of the authorization flow used. PKCE in use with PAR is a requirement in FAPI 1.0 Final"
Could you confirm, if DR follows Hybrid flow, then also PKCE claims needs to be sent when making PAR endpoint call? If the answer is "YES", then how would this enforce additional security, as hybrid flow doesn't mandate PKCE claims to be sent.
2. If a DR registers with DH to follow hybrid flow, while making a PAR end point call, can they switch to Authorization code flow?
3. Should there be validation enforced at PAR endpoint to check what DR has mentioned during client registration, they are following the same? If they don't should auth server reject the request with status code 403?
4. Is there a possibility for DR to register with DH to support both hybrid and Authorization code flow?
5. Should OIDC endpoint response, expose the PKCE and JARM claims to the DR. If yes, would the non normative examples be updated later on?		 Question 1: Could you confirm, if DR follows Hybrid flow, then also PKCE claims needs to be sent when making PAR endpoint call?
[Answer 1 ] In this situation the overriding standard is the FAPI 1.0 profile. Please refer to the footnote of FAPI 1.0 Advances section 5.2.2:
NOTE: PAR does not present any additional security concerns that necessitated the requirement to use PKCE - the reason PKCE is not required in other cases is merely to be backwards compatible with earlier drafts of this standard.
Question 2. If a DR registers with DH to follow hybrid flow, while making a PAR end point call, can they switch to Authorization code flow?
[Answer] No. The flow is determined using the response_type. The client must only use a response_type that the DH advertises support for in their response_types parameter value array.
Question 3. Should there be validation enforced at PAR endpoint to check what DR has mentioned during client registration, they are following the same? If they don't should auth server reject the request with status code 403?
[Answer] This should be standard Authorisation Server behaviour
Question 4. Is there a possibility for DR to register with DH to support both hybrid and Authorization code flow?
[Answer] Yes a client may register all response_types it supports
Question 5. Should OIDC endpoint response, expose the PKCE and JARM claims to the DR. If yes, would the non normative examples be updated later on?
[Answer] I don't understand the question however the non-normative examples are being updated in Maintenance Iteration 11: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/458
1518 Error response for a consent authorisation with request_uri bound to different ADR
What should be the error response for a consent initiation attempt for an ADR with a request_uri bound to different ADR?
Does an error like "Signature verification failure" is appropriate or else can u give your ideas on what error should look like?		 you would need to refer to the upstream specification. What you describe is an invalid client authentication against the request_uri.
1520 Profile Scope
Could you please clarify the below questions on the Profile scope changes introduced via DP216?
1. Must Data Holders support the email, address and phone scope as per OIDC 5.4? Or are only the openid and profile scope mandatory and these extra ones are optional?
2. Is there a CDR requirement around how up to date the custome data returned via the profile scope must be? Is it acceptable to return the data at the time of the consent creation? If not what is an acceptable timeframe?
3. Must Data Holders support requests for individual claims via the “claims” request parameter as per OIDC 5.5 or it’s an optional implementation as the OIDC 5.5 states it’s OPTIONAL? That is do data holders need to support the id_token and userinfo members of the claims parameter. If so, which specifiers are required for the claims supported. [null, essential, value, values]		 Question 1. Must Data Holders support the email, address and phone scope as per OIDC 5.4? Or are only the openid and profile scope mandatory and these extra ones are optional?
Answer 1: No. These scopes are not supported in the data standards.
Question 2. Is there a CDR requirement around how up to date the customer data returned via the profile scope must be? Is it acceptable to return the data at the time of the consent creation? If not what is an acceptable timeframe?
Answer 2: There are non-functional requirements regarding Data Latency. The data must be current in accordance to your other changes, the OAIC Australian Privacy Principles and your existing industry regulatory requirements. Please refer to Data Latency: https://consumerdatastandardsaustralia.github.io/standards/index.html#data-latency
Question 3. Must Data Holders support requests for individual claims via the “claims” request parameter as per OIDC 5.5 or it’s an optional implementation as the OIDC 5.5 states it’s OPTIONAL?
Answer 3: Yes. The PII claims specified and ACR values are examples. Sub, air and auth_time must always be provided regardless of them being requested as individual claims.
1522 Scheduled Payments and Direct Debits requests where there is no data
Where a request is made to either get scheduled payments or direct debits on one or multiple accounts and there are no scheduled payments or direct debits on the account. What should the response be. i.e. Status Ok with an empty array or an error code as the mandatory fields can't be populated.		 if the request is valid you must respond with a 200 OK and an empty array.
1536 Part 1 Clarification on lendingRate.rate and lendingRate.repaymentType
If an organization doesn't charge any Interest from it's customer for a Loan, what should be probable values for below fields
1. lendingRate.repaymentType - Fixed Value - PRINCIPAL_AND_INTEREST ? As we don't have any Value with just says "PRINCIPAL"
2. lendingRate.rate - As this is a mandatory field, can we default it to "0"(Zero) as organization doesn't charge any interest ?		 this is at the discretion of the Data Holder.
If you have a loan without any repayable interest, expressing the lending rates in the way you have expressed would seem to be correct.
1536 Part 2 can you answer on item 1: can we go ahead with "PRINCIPAL_AND_INTEREST" or AUCDR will introduce a new type called "PRINCIPAL" ? 1. lendingRate.repaymentType - Fixed Value - PRINCIPAL_AND_INTEREST ? As we don't have any Value with just says "PRINCIPAL" there is no "PRINCIPAL" repayment type. For this to be considered, we would encourage you to raise a change request to consider this. In the meantime, if I understand your product correctly, the way I've described above should allow you to represent it correctly.
1549 As part of the OIDC Authorization Code Flow, Data Holders are expected to support JARM. Questions:
1. For the "authorization_signed_response_alg attribute" should the DH use PS256 or leave it to default which is RS256?
2. Should the JWT be encrypted? 3. If yes, what should be the OB recommended values list for these attributes.
a. authorization_encrypted_response_alg
b. authorization_encrypted_response_enc		 Question 1: For the "authorization_signed_response_alg attribute" should the DH use PS256 or leave it to default which is RS256?
Answer 1: RS256 is explicitly excluded by FAPI. FAPI provides requirements for allowed signing algorithms in section 8.6: https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations
Question 2. Should the JWT be encrypted?
Answer 2: No. There is currently some discussion in the Maintenance Iteration 11 to exclude encryption of responses (this would be a constraint to the JARM spec)
Question 3. If yes, what should be the OB recommended values list for these attributes.
a. authorization_encrypted_response_alg
b. authorization_encrypted_response_enc
Answer 3: Currently, the algorithms specified in JWE apply. The JARM spec states these requirements. https://openid.net/specs/openid-financial-api-jarm.html in section 6: https://openid.net/specs/openid-financial-api-jarm.html#authorization-server-metadata
- authorization_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.
- authorization_encryption_enc_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (enc values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.
1557 We have a question for the FAPI 1.0 upgrade (i.e. https://github.com/ConsumerDataStandardsAustralia/standards/issues/209)
For September 16th obligation date, under the heading of "Authorization Code Flow" it states "Data Holders MAY support the Authorization Code Flow in accordance with FAPI 1.0 Advanced. This requires JARM and PKCE."
The above statement states "MAY" however in the 'Future Dated Obligation' page for September 16th 2022, it states "Data Holders and Data Recipients MUST support FAPI 1.0 Final including [RFC9126], [RFC7636] and [JARM]".
The 2 sites contradicts each other as one says "MAY" and the other says "MUST".
Can you please let us know if it's indeed a "MAY" or "MUST" so we can prioritise our upgrade ?		 the intention of the statements in the future dated obligations is to indicate any Data Holder adopting Authorization Code Flow in Phase 2 must do so according to FAPI 1.0 Final including [RFC9126], [RFC7636] and [JARM].
The requirement for Authorization Code Flow support in Phase 2 is actually a SHOULD, not a MAY, but this does give discretion to the Data Holder. Whilst we encourage Data Holders to implement and support the Authorization Code Flow from September, it is only mandated from April 2023 (after which time the OIDC Hybrid Flow is deprecated). Please note that "MAY" support for Authorization Code Flow is July 2022, "SHOULD" support is September 2022 and "MUST" support is April 2023.
1566 DP 212 - Adding Unique JTIs in Self Signed JWTs
The following has been mentioned in DP 212 to minimize mixup attacks.
Decision
The decision is to adopt changes as an urgent security fix to minimize a potential mixup attack on the Data Recipient CDR Arrangement Revocation endpoint. The decision is to make the following changes:
1. Self-Signed JWTs MUST be assigned a unique 'jti' value and MUST only be used once by the Data Holder
2. Data Recipients MUST enforce unique 'jti' values and reject JWTs where the 'jti' has previously been provided
3. Replace the cdr_arrangement_id parameter with a Data Holder signed JWT containing the cdr_arrangement_id as the only parameter. This change segregates authentication logic from business logic.
What is the exact requirement from the 1st & 2nd changes mentioned above? If we consider the following request for /arrangements/revoke endpoint,
- Should JTI values in the client authentication JWT & cdr_arrangement_jwt be different?
or
- Can they both be the same in one /arrangements/revoke request and unique from one request to another?
POST https://data.recipient.com.au/arrangements/revoke HTTP/1.1
Host: data.recipient.com.au
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey …
cdr_arrangement_jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6IjEyNDU2In0.ey ...		 the "jti" (JWT ID) claim provides a unique identifier for the JWT. This means that it should be unique (with negligible change of collision) across different JWTs. See section 4.1.7 of the JWT RFC for details: https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7.
1570 Maintenance Iteration 10 includes issue #453: Consider an upper bound on trusting entity statuses when they go missing. It doesn't appear to have any obligation date. As such, can you please confirm if that is just an optional item with no obligation date? What changes are required if our systems stop processing all records if we receive a status that is invalid? i.e. to ignore invalid statuses without failing? The original change related to this is issue 433 which was addressed in maintenance iteration 9. This sets the requirement for data holders as: If Data Holders do not receive a status for a Data Recipient or Data Recipient Software Product, or receives a status that is not recognised, Data Holders SHOULD ignore the value and use the previous status value retrieved from the CDR Register. Your implementation needs to align with this requirement. The rationale here is that an outage of the Register, or a faulty deployment, should not result in an outage of the CDR.

Issue 453 resulted in the clarification of the requirement set out in Issue 433: If Data Holders do not receive a status for a Data Recipient or Data Recipient Software Product, or receives a status that is not recognised, Data Holders SHOULD ignore the value and use the previous status value retrieved from the CDR Register. Data Holders SHOULD continue to use the previous status value until a valid value is returned by the CDR Register or the ACCC informs the Data Holder using an alternative mechanism. There is no upper bound for how long previous status values should remain trusted.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally