DSB Item - Feature Negotiation in the CDR

[CDR-API-Stream]

Problem Statement

A review of the current state of feature negotiation in the CDR is required to understand the opportunities for improvement and what foundational work is required for the future state

[CDR-API-Stream]

Feature negotiation is being tackled in 3 stages of work:
 

1. Identify and address the current gaps within the current feature negotiation mechanisms/design.
    
   This work has been heavily influenced by the introduction of multiple sectors to the CDR ecosystem. This stage is being worked through the maintenance iteration process. Issues targeted during this stage include:
    

• API Uplift for Data Recipient Multi-Sector support #425
   
• API Uplift for Data Holder Multi-Sector support #424
   
• Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API #444
   
• Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products #486
   
• Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes #488
   
   

2. Identify where the current feature negotiation mechanisms can be simplified/standardised. This will ensure changes to the standards resulting in changes to feature negotiation is a less complex exercise
    
3. Identify what foundational work is required to enable future functionality such as action initiation
    
    
   Currently, the focus has been on stage 1, facilitated through the maintenance iteration process.

[nils-work]

The Stage 1 items mentioned in the previous comment are now closed.

Stage 2 items may include:

• #443 SSA definition: Deprecation of revocation_uri
• #484 1.13.0 Appears to have introduced new SSA error behaviours
• Clarify whether legal_entity_id and legal_entity_name are Optional or Required fields in an SSA