Data plane signaling token refresh feedback

[lholthof]

The data plane signaling concept has been checked by us and brought up two major changes in the design principle of EDC’s data plane.

(a) Dataplane becomes stateful. This means knowledge about the transferprocess state is required to decide about processing the message or not.
(b) Tokens are infinite -> By design TX EDC would generate JWTs without expiry and authentication is majorly based on (a)
As we have plugged our proprietary data plane into our connector (a) is contradicting our setup. In addition (b) represents a security flaw for us.

After initial discussions we were told that (a) can be replaced by a custom implementation and for (b) a token renewal procedure should be found.

This discussion should focus on resolving (b) which we saw described within:tx-signaling.extensions.md

I will number our feedback / questions to that solution.

Option 1 “Lazy refresh” on data plane

(1) This requires the consumer always to call via the consumer’s data plane. In our current consumed EDC version 0.6.0/0.5.3 this is not the default behavior anymore. Instead the endpoint provided to consumer clients are the provider’s data plane and the extra hop via consumer’s data plane is omitted. Is the default changing in 0.7.0 again? In case we are providers, the consumer behavior is out of our control and we would rely on at least TX EDC implementation’s default behavior.

(2) How does the consumer client authenticate against the consumer data plane? If the token is refreshed internally inside data plane, how does the client become to know the new access token? Or if there are multiple clients, would the refresh be triggered for each one? For us an access token must be short-lived and the refresh token (also limited lifetime) has to be kept secure in a vault. If the token refresh is transparent for the client, the access token used by the client is actually infinite which would be a security flaw for us as well.

(3) Relying just on HTTP return code 401 to trigger the token refresh sounds dangerous. It could be mixed up with real Unauthenticated Calls which then would trigger a refresh. We suggest to check the token’s validity in addition / or even better before the call. The validity can either be derived by reading the JWT or by persisting the expiry time (token received time + expiresIn).

Option 2 Token refresh via Management API

(4) A mitigation for (a) is that the access token has limited lifetime and policy enforcement and the actual calls can only deviate by the token validity. Hence the policy evaluation upon token refresh is key to the overall process. In the current version 0.6.0/0.5.3 the SSI/MIW Verifiable Credentials are the major base for any policy evaluation. As the suggestion is currently not based upon a DSP message, I think the MIW authentication is also not planned. Hence a policy evaluation with current credentials is not possible.
Our suggestion would be to also cover the /token/refresh endpoint with SSI/MIW authentication. This would allow to perform policy enforcement as part of the token renewal. In the current refresh profile it is specified to send an access token holding the DID itself, but this would not suffice to grant access to the VCs.

(5) How does the /edrs API fit into this solution option? Reason for this API was to take complexity off the clients and hence the expectation of our clients is that renewal is handled internally.

Option 3: Out-of-band token renewal

Not standardized token renewal would evolve in partner specific processes which are decrease interoperability within the data spaces. The consumer clients would have to implement provider specific knowledge and in addition credentials to trigger the token renewal would have to be spread across the consumer clients. As already stated in your paper this is to be prevented.

Refresh token grant profile

It is great to see the refresh token profile already specified on a very detailed level and to have it following known oauth2 standards roughly.

(6) Would you implement a mechanism to guarantee idempotency for the token renewal. The renewal must not be triggered twice with the same refresh token as this usually would indicate a security breach.

(7) There is a refreshTokenType specified for future use. For accessTokens the tokenType usually indicates the prefix to add to the token, i.e. bearer. Maybe grant_type would fit better if other semantics should be covered as such a type.

(8) The TransferStartMessage contains token details as part of dspace:endpointProperties. I suggest to introduce a dedicated type dspace:authentication with the contents you defined dspace:refreshToken, dspace:expiresIn, dspace:refreshEndpoint, dspace:refreshTokenType plus the access token details like dspace:accessToken, dspace:accessTokenType

(9) Will some process cover expired refreshTokens? The corresponding transferprocess is not usable in that case and has to be "restarted".

I appreciate to get into discussion about those items.