-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The protocol already states about the client (wallet) to share a public key through the self-issued id tokens.
Here, the idea would be to use the protocol to primarily share encryption keys in order for both the authorization server and the client to be able to encrypt information, process that would be free to the implementer.
The suggestion would be to add a parameter containing an encryption key to the self-issued openid provider request for the client to securely encrypt content and to have the client encryption key shared with the authorization server along with the id_token in the response.
Both the client and the authorization server would then have the ability to encrypt messages to create a secure channel between the two entities. Going further, it may be a way to encrypt further protocol messages like oauth/openid parameters and responses, SIOPv2 acting as a back channel to secure the communications.
I am not sure about the security implications of such a way to create a secure channel and if it might be helpful for the identity use cases, hoping it provides more secure exchanges.