Support for Multiple Profiles Per Stream

[Phil Hunt]

Many sites will want to see a full picture of security that may include multiple event profile types. For example, many RPs want session control and RISC events since RISC events often lead to a decision to suspend or revoke local sessions.

This was discussed in the IETF 100 side meeting on Nov 10 (in which RISC member attendance was also a majority of attendees): https://www.ietf.org/mail-archive/web/id-event/current/msg00827.html

From the minutes: * If Profiles define control plane independently, then it will make adoption much more complicated for Receivers. Google pointed out that its Receivers won't care whether events are defined in OAuth, OIDC and RISC- it will add a lot of complexity to have to re-establish control plane for each of these separately. We want to send all these events to a single end point for each receiver since all of these events are ultimately tied back to the same logical OAuth client. * Independent stream config for each profile adds a lot of complexity for the Receiver and only a few large Receivers want to be able to send streams directly to each sub-system. It's reasonable to push this complexity on the large Receivers to set up routers for SecEvents going to the relevant sub-system.

This issue is marked blocker because this is a go/nogo discussion on producing RISC specific profiles for transfer of messages.

[Dick Hardt]

Nothing prevents different control planes from managing sending signals from different profiles to the same endpoint if desired.

Additionally, events are asynchronous and independant, so it is unclear why signals need to come over the same endpoint. They can arrive on different end points.

[Marius Scurtescu]

Happy to move the control plane definition out of the RISC Profile to IETF, if the secevent working group shows interest. We are doing the exact same thing right now with subject identifiers.