Release/1.7.0 minor fix

docs/includes/releasenotes/releasenotes.1.7.0.html

@@ -273,13 +273,27 @@ <h2 id='api-end-points'>API End Points</h2>
 <th>Link</th>
 </tr>
 </thead><tbody>
+<tr>
+<td>Fixed paymentsRemaining value in Scheduled Payment non-normative examples</td>
+<td>Non-normative examples showed paymentsRemaining = 0 however paymentsRemaining is a PositiveInteger with a value of 1 or greater.</td>
+<td><a href="../../#get-scheduled-payments-for-account">Scheduled Payments APIs</a></td>
+</tr>
+<tr>
+<td>Scheduled Payments</td>
+<td>Corrected the description for the scheduled payment nickname and made payeeReference conditional, to be provided only if there is a global payee reference for the payment set. Introduced conditional payeeReference and nickname for the individualised payments in the scheduled payment set</td>
+<td><a href="../../#tocSbankingscheduledpayment">BankingScheduledPayment</a></td>
+</tr>
+<tr>
+<td>Updated CRN description</td>
+<td>The CRN description was updated for BankingBillerPayee and BankingTransaction to appropriately reference conditionality of the response based on data sensitivity considerations and availability of the data for the posted transaction or saved payee.</td>
+<td></td>
+</tr>
+<tr>
+<td>Draft Energy Standards Update</td>
+<td>Updated the draft energy standards to accommodate the feedback from DP 149</td>
+<td><a href="../../draft/energy-draft.html">Draft Energy Standards</a></td>
+</tr>
 </tbody></table>
-
-<p>=======
-| Fixed paymentsRemaining value in Scheduled Payment non-normative examples | Non-normative examples showed paymentsRemaining = 0 however paymentsRemaining is a PositiveInteger with a value of 1 or greater. | <a href="../../#get-scheduled-payments-for-account">Scheduled Payments APIs</a> |
-| Scheduled Payments | Corrected the description for the scheduled payment nickname and made payeeReference conditional, to be provided only if there is a global payee reference for the payment set. Introduced conditional payeeReference and nickname for the individualised payments in the scheduled payment set | <a href="../../#tocSbankingscheduledpayment">BankingScheduledPayment</a> |
-| Updated CRN description | The CRN description was updated for BankingBillerPayee and BankingTransaction to appropriately reference conditionality of the response based on data sensitivity considerations and availability of the data for the posted transaction or saved payee. |
-| Draft Energy Standards Update | Updated the draft energy standards to accommodate the feedback from DP 149 | <a href="../../draft/energy-draft.html">Draft Energy Standards</a> |</p>
 <h2 id='information-security-profile'>Information Security Profile</h2>
 <table><thead>
 <tr>
@@ -289,9 +303,9 @@ <h2 id='information-security-profile'>Information Security Profile</h2>
 </tr>
 </thead><tbody>
 <tr>
-<td></td>
-<td></td>
-<td></td>
+<td>One-Time Collection Consent</td>
+<td>Clarified that one-time collection consent is permitted for a shraring duration up to 24 hours. This allows the Data Recipient to obtain a Refresh Token to collect data over a period longer than a single Access Token in case of technical issues during collection</td>
+<td><a href="../../#requesting-sharing-duration">Requesting Sharing Duration</a></td>
 </tr>
 </tbody></table>
 <h2 id='consumer-experience'>Consumer Experience</h2>

docs/index.html

@@ -835,14 +835,26 @@ <h2 id='future-dated-obligations'>Future Dated Obligations</h2>
 <td>Client Authentication has been updated to align to upstream standards. From March 30th 2021, Data Holders must support multiple valid values for the audience claim for Data Recipient client authentication as outlined in that section. Data Recipients may continue to supply the URL of the endpoint being invoked, however according to upstream standards, it is recommended according to <strong>[RFC8414]</strong> that issuer identifier URL of the authorisation server should be used as the value of the audience.<br/>Until March 31st 2021, Data Recipients must continue to use the URL of the endpoint being invoked as the audience claim value. Data Holders must continue to accept and validate the URL of the endpoint being invoked.</td>
 <td>March 30th 2021</td>
 </tr>
+<tr>
+<td><a href="#get-customer">Get Customer V1</a></td>
+<td>Data Holders providing valid ANZSIC and ANZSCO codes whose version is not ANZSIC_1292.0_2006_V2.0 and ANZSCO_1220.0_2013_V1.2 respectively must supply the appropriate version enumeration no later than July 1st 2021. The version codes allow data holders to reference the applicable document versions for the codes they hold.</td>
+<td>July 1st 2021</td>
+</tr>
+<tr>
+<td><a href="#product-amp-account-components">Banking Term Deposit Account Types</a></td>
+<td>Data Holders who support maturity instructions for term deposits whereby funds are held in a facility or similar mechanism upon maturity must update relevant product data no later than July 1st 2021</td>
+<td>July 1st 2021</td>
+</tr>
+<tr>
+<td><a href="#end-points">Token Introspection Endpoint claims</a></td>
+<td>Mandatory claims were updated in accordance with RFC7662</td>
+<td>November 1st 2020</td>
+</tr>
 </tbody></table>
 <h2 id='endpoint-version-schedule'>Endpoint Version Schedule</h2>
 <p>A table-view of all endpoint versioning is available <a href='includes/endpoint-version-schedule/'>here</a>.</p>
 
-<p><strong>Please note</strong> this is currently experimental.
-| <a href="#get-customer">Get Customer V1</a> | Data Holders providing valid ANZSIC and ANZSCO codes whose version is not ANZSIC_1292.0_2006_V2.0 and ANZSCO_1220.0_2013_V1.2 respectively must supply the appropriate version enumeration no later than July 1st 2021. The version codes allow data holders to reference the applicable document versions for the codes they hold. | July 1st 2021 |
-| <a href="#product-amp-account-components">Banking Term Deposit Account Types</a> | Data Holders who support maturity instructions for term deposits whereby funds are held in a facility or similar mechanism upon maturity must update relevant product data no later than July 1st 2021 | July 1st 2021 |
-| <a href="#end-points">Token Introspection Endpoint claims</a> | Mandatory claims were updated in accordance with RFC7662 | November 1st 2020 |</p>
+<p><strong>Please note</strong> this is currently experimental.</p>
 <h1 id='standards'>Standards</h1>
 <p>These standards represent <strong>version 1.7.0</strong> of the high level standards.  See the <a href="#versioning">versioning section</a> for more information on how versions are managed in the standard.</p>
 
@@ -2476,7 +2488,9 @@ <h3 id='requesting-sharing-duration'>Requesting Sharing Duration</h3>
 <li>The <code>sharing_duration</code> parameter is a number</li>
 <li>The value of the <code>sharing_duration</code> parameter will contain the requested duration for sharing, in seconds.</li>
 <li>If the <code>sharing_duration</code> value exceeds one year then a duration of one year will be assumed.</li>
+<li>  If the <code>sharing_duration</code> value is less than or equal to 24 hours, then one-time collection will be assumed, and a Refresh Token should be provided by the Data Holder</li>
 <li>If the <code>sharing_duration</code> value is zero or absent then once off access will be assumed and only an Access Token (without a Refresh Token) will be provided on successful authorisation.</li>
+<li>  If a Refresh Token is issued for one-time collection the Data Recipient must call the Data Holder’s revocation endpoint after successful collection of the CDR data.</li>
 <li>If the <code>sharing_duration</code> value is negative then the authorisation should fail.</li>
 </ul>
 

slate/source/includes/_security.md.erb

@@ -611,7 +611,9 @@ To accomplish this, the Data Holder MUST support an additional claim in the auth
 - The `sharing_duration` parameter is a number
 - The value of the `sharing_duration` parameter will contain the requested duration for sharing, in seconds.
 - If the `sharing_duration` value exceeds one year then a duration of one year will be assumed.
+-	If the `sharing_duration` value is less than or equal to 24 hours, then one-time collection will be assumed, and a Refresh Token should be provided by the Data Holder
 - If the `sharing_duration` value is zero or absent then once off access will be assumed and only an Access Token (without a Refresh Token) will be provided on successful authorisation.
+-	If a Refresh Token is issued for one-time collection the Data Recipient must call the Data Holder’s revocation endpoint after successful collection of the CDR data.
 - If the `sharing_duration` value is negative then the authorisation should fail.
 
 Note that the period of `one year` in the above statements should be interpreted as 365, 24 hour days (or 31,536,000 seconds).

slate/source/includes/releasenotes/releasenotes.1.7.0.html.md

@@ -26,7 +26,6 @@ This release pertains to the changes approved by the Data Standards Chair in [De
 
 |Change|Description|Link|
 |------|-----------|----|
-=======
 | Fixed paymentsRemaining value in Scheduled Payment non-normative examples | Non-normative examples showed paymentsRemaining = 0 however paymentsRemaining is a PositiveInteger with a value of 1 or greater. | [Scheduled Payments APIs](../../#get-scheduled-payments-for-account) |
 | Scheduled Payments | Corrected the description for the scheduled payment nickname and made payeeReference conditional, to be provided only if there is a global payee reference for the payment set. Introduced conditional payeeReference and nickname for the individualised payments in the scheduled payment set | [BankingScheduledPayment](../../#tocSbankingscheduledpayment) |
 | Updated CRN description | The CRN description was updated for BankingBillerPayee and BankingTransaction to appropriately reference conditionality of the response based on data sensitivity considerations and availability of the data for the posted transaction or saved payee. |
@@ -35,7 +34,7 @@ This release pertains to the changes approved by the Data Standards Chair in [De
 ## Information Security Profile
 |Change|Description|Link|
 |------|-----------|----|
-|  |  |
+| One-Time Collection Consent | Clarified that one-time collection consent is permitted for a shraring duration up to 24 hours. This allows the Data Recipient to obtain a Refresh Token to collect data over a period longer than a single Access Token in case of technical issues during collection  | [Requesting Sharing Duration](../../#requesting-sharing-duration) |
 
 ## Consumer Experience