Assumption of Client ID as Receiver

[Phil Hunt]

Many relying parties have discreet security components which means that it cannot be assumed that it is the OIDC Connect client that is the receiver. For example, a receiver may be a designated third-party security broker (CASB). In such cases it would be a bad security practice for the RP web site to share their client credential.

Additionally, in the reverse direction where web sites generate events: a couple of scenarios must be accounted for: * The transmitter is the RP itself. The credentials must be able to work in reverse orientation. E.g. what credentials does the OP use to access the RP Control Plane. The RP may or may not have capability to issue oauth tokens. * In cases of CASB, the transmitter (e.g CASB or web site) may not be part of the OIDC federation relationship. For example a third-party security firm (a CASB broker) may be issuing events based on activity analysis of the long-tail site.

Impact: Communication is bi-directional and any security authorization schema must work in both directions and with third parties.

[Marius Scurtescu]

client id as receiver is only suggested as possibility if OAuth 2 is used, there is no hard requirement anymore