You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Draft 4 there is a callout in Section 2.1 around "SCIM Events SHALL use the "sub_id" claim defined by Subject Identifiers for Security Event Tokens [RFC9493] specification to identify the subject of events. The sub_id claim MUST be contained within the main JWT claims body and SHALL NOT be located within an Event payload within the events claim." Which is great to hear as a change from Draft 3 to 4.
The ask is to have examples using other formats than "scim" to show applicablity, such as "alias". Having the direct callout in one example would be sufficient but should be extended to using another format for a different example in the draft.
In Section 3, under eventUris, RFC8935 and RFC8936 are called out for generating and deliverable via a SET Stream, but there is not a mention to honor and/or use the Shared Signals Framework for the transmission and receipt of these SCIM Events. The way SSF is heading in the WG is to act as the orchestration mechanism and sharing of signals between cooperating peers. SSF will honor events of type: CAEP/RISC and now SCIM among others coming.
The text was updated successfully, but these errors were encountered:
There are issues with SSF supporting SCIM. But these are all on the SSF side. There is nothing in this spec that precludes using SSF.
The chief problem is that to date, SSF does not want to consider cases where entities can be either transmitters or receivers or both. They also don't consider the case of gateways and aggregation that are likely to be required in clustered scenarios.
Remember that SSF is just a stream management api. SSF does not define how to exchange events. These are IETF specs.
In Draft 4 there is a callout in Section 2.1 around "SCIM Events SHALL use the "sub_id" claim defined by Subject Identifiers for Security Event Tokens [RFC9493] specification to identify the subject of events. The sub_id claim MUST be contained within the main JWT claims body and SHALL NOT be located within an Event payload within the events claim." Which is great to hear as a change from Draft 3 to 4.
The ask is to have examples using other formats than "scim" to show applicablity, such as "alias". Having the direct callout in one example would be sufficient but should be extended to using another format for a different example in the draft.
In Section 3, under eventUris, RFC8935 and RFC8936 are called out for generating and deliverable via a SET Stream, but there is not a mention to honor and/or use the Shared Signals Framework for the transmission and receipt of these SCIM Events. The way SSF is heading in the WG is to act as the orchestration mechanism and sharing of signals between cooperating peers. SSF will honor events of type: CAEP/RISC and now SCIM among others coming.
The text was updated successfully, but these errors were encountered: