Cleaned up version deltas to follow conventions

ConsumerDataStandardsAustralia · May 23, 2022 · 64a87ee · 64a87ee
1 parent 9662c9a
commit 64a87ee
Show file tree

Hide file tree

Showing 3 changed files with 5 additions and 4 deletions.
diff --git a/slate/source/includes/_register.md.erb b/slate/source/includes/_register.md.erb
@@ -45,8 +45,7 @@ standards.
 
 + Added GetDataHolderBrandsSummary API to expose public details of Data Holder Brands from the CDR Register to public clients
 
-* x-v header requirements for versioned Register APIs moved from mandatory to optional
-
+x-v header requirements for versioned Register APIs moved from mandatory to optional
 ```
 
 <%= partial "includes/cds_register.md" %>
diff --git a/slate/source/includes/security/_client_registration.md.erb b/slate/source/includes/security/_client_registration.md.erb
@@ -216,7 +216,8 @@ Participants **MUST** support, at a minimum, the following ID Token algorithms:
 ### Registration Validation
 
 ```diff
-+ Added requirement for data holders to ignore unsupported authorisation scopes
+Added the following requirement:
++ Data Holders MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of client registrations.
 ```
 
 Validation and use of the JWT and the claims described above **MUST** be performed in accordance with **[[JWT]](#nref-JWT)**.

diff --git a/slate/source/includes/security/_participant_statuses.md.erb b/slate/source/includes/security/_participant_statuses.md.erb
@@ -57,7 +57,8 @@ The table below outlines the end state for each Register entry type:
 ### Data Holder Responsibilities
 
 ```diff
-+ Added clarification that when statuses are not received or recognised from the CDR Register, the ACCC can inform Data Holders of statuses to trust using an alternative mechanism. There is no upper bound for how long previous status values should remain trusted.
+Added the following requirement:
++ 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.
 ```
 
 The CDR Registrar has the ability to change the status of a Software Product independently of the Data Recipient's accreditation status. Therefore, both the Data Recipient and Software Product statuses **SHOULD** be referenced, to determine the Data Holder's responsibilities for data disclosure, consent and registration management.