Decide how to implement Client Credentials

[peterbrightwell]

Proposal is to use this approach to tackle #62 and #75 for v1.0

[cristian-recoseanu]

We have pondered some more on this decision internally at Pebble and have some concerns which we wanted to share with the group. Assumptions: Client Credentials grant is implemented in such a way that it allows nodes to retrieve access tokens for the IS-04 scope with ease.

Does this approach reduce security to an extent whereby it can enable the following security risks to happen:

• A malicious node can easily request an IS-04 scoped token using the Client Credentials grant and then query the whole registry and have a lot of information to base further attacks on.
• A malicious node can easily request an IS-04 scoped token using the Client Credentials grant and then perform a denial of service attacks on the registry by registering a tremendous amount of resources.

Would it be better to attempt to resolve bulk authorization by delegating to a control system/authorization client?

Proposal: Authorized registries have a new topic and registration area called authorization_intent.

Nodes host an /oauth endpoint which starts the authorization process using the Authorization Code grant type.

Nodes register their authorization_intent object in this area in the registry, making them visible to the rest of the system. The authorization_intent object contains useful information about the node in question (TBD).

A control system or an authorization client would subscribe to this topic on the registry and identity all the nodes wishing to authorize. It would then offer a UI which a user can click through all of the pending nodes and redirect to their /oauth endpoint kick starting the authorization process.

This would simplify the authorization process by offering a quicker way of clicking through the pending list of nodes requiring authorization but still maintain our current level of security.

Once logged in to the authorization server for the first node being authorized the user may have the username and password already remembered so subsequent authorization actions only involve clicking on the “OK” or “Accept” button for every node.

[peterbrightwell]

Discussion on call today: Experiments at Sony suggest Keycloak can be used effectively to programatically get access token for initial client registration, but not sure about other auth servers. We should also look at "software statement" approach (JWT with software ID details, signed by vendor) before deciding.

[lo-simon]

see use case at the end of #84

[peterbrightwell]

Sony: Evidence of support for software statements found in 4 out of 30 surveyed including Connect2id. Some big players (Oracle, MS Azure) don't support. Will try a connect2id server. BBC: OpenAM version of Forgerock doesn't support it. MitreID has minimal user interface and it's not clear how to verify operation. Also worth checking Ping Identity and PingFederate cloud service.

We still think software statement is the preferred approach with initial access mechanism as fallback -- but should be prepared to revisit.