RFC072: Authentication Assurance Levels

Background and rationale

Within DSGO we allow service providers and service consumers to use different authentication mechanisms for M2M. The main reason is that 1) parties are starting with APIs and 2) the electronic seals are not mature enough.

Proposed change: purpose

We propose three things:

  1. Support advanced electronic seals in addition to qualified electronic seals. This is already possible in iSHARE and added to the DSGO as an option. For more info see RFC016 - Electronic seals (AdSeal en QSeal)
  2. Support ClientSecret authentication as an option for service consumers. The service provider may support this and still must support client_assertions. ClientSecret is allowed under specific conditions. For more info see RFC017 - Authenticatie-oplossing ClientPassword (Client - Secret)
  3. Add an attribute aal Authentication Assurance Level to the capability_info object. This attribute shows the authentication options for a certain endpoint. For example a highly secure endpoint can have the only option of QSeal and a more open endpoint can have multiple options: [QSeal, AdSeal, ClientPassword]. In the latter, the service consumer can choose its authentication method of preference.

Proposed change: considerations and requirements

By adding authentication assurance levels we extend the iSHARE framework to data sharing use cases that does not require the highest security standards. On the other hand, high security standards are still supported. Moreover, we have chosen that service providers must always support the highest level of authentication. This ensures that all data services are future proof for client_assertions.