We have in the Signature Extension for OpenID Connect specification defined a mechanism for how a Relying Party can include a signRequest parameter along with a sign scope in an request in order to sign some arbitrary data. This will lead to that an OP (with signature capabilities) makes the user the data and returns the signature in the ID Token.
However, in many cases, the OP itself isn't the entity that actual entity that is in charge of the signature creation. In delegated signing processes the OP may only be one part of the entire signing process. For example, in the Sweden Connect case, there is a Signature Service to which a user is directed by a RP in order to produce a signature. In those cases, the entity that actually signs is the Signature Service on behalf of the user. The user has to authenticate and approve that the Signature Service generates a key pair and signs the data.
We have in the Signature Extension for OpenID Connect specification defined a mechanism for how a Relying Party can include a
signRequest
parameter along with asign
scope in an request in order to sign some arbitrary data. This will lead to that an OP (with signature capabilities) makes the user the data and returns the signature in the ID Token.However, in many cases, the OP itself isn't the entity that actual entity that is in charge of the signature creation. In delegated signing processes the OP may only be one part of the entire signing process. For example, in the Sweden Connect case, there is a Signature Service to which a user is directed by a RP in order to produce a signature. In those cases, the entity that actually signs is the Signature Service on behalf of the user. The user has to authenticate and approve that the Signature Service generates a key pair and signs the data.
Therefore, I suggest that we extend the Signature Extension for OpenID Connect specification with support for this use case.
This will involve:
signApproval
.