When the timeld Gateway is transmitting messages with signatures for integrity and/or non-repudiation to a federated system via its respective Connector, it is necessary that those signatures connote verification of the original messages received by the Gateway's m-ld clone from CLI clones. In other words, the Gateway is regarded as signing messages on behalf of the timeld CLI instances connected to it.
Motivation: it is not feasible for a another federated time-tracking application to directly validate user updates, because it would need to:
obtain the public key of the timeld CLI instances' m-ld clones that sent the original operation messages, and
decode the native m-ld operations signed by those clones
Therefore, the Gateway needs to act as their trusted proxy in this regard.
gsvarovsky
commented
1 year ago
When the timeld Gateway is transmitting messages with signatures for integrity and/or non-repudiation to a federated system via its respective Connector, it is necessary that those signatures connote verification of the original messages received by the Gateway's m-ld clone from CLI clones. In other words, the Gateway is regarded as signing messages on behalf of the timeld CLI instances connected to it.
Motivation: it is not feasible for a another federated time-tracking application to directly validate user updates, because it would need to:
Therefore, the Gateway needs to act as their trusted proxy in this regard.