search

ietf-scim-wg / draft-ietf-scim-events

Working material for the IETF SCIM Events draft
Other
5 stars 3 forks source link

Suggestions for additional Includes for Direct SSF Callout and including examples for sub_id formats #36

Closed iamseanodentity closed 7 months ago

iamseanodentity commented 8 months ago

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.

independentid commented 7 months ago

I think this should be presented and discussed in the next group.

I feel there are a lot of downsides and interopability complications that this would introduce.

My feeling is to keep the scim spec focused on scim stuff.

derrumbe commented 7 months ago

(1) - do you already have an example sitting around? let's talk about it

(2) As long as it's not opposed to SSF, leaving it agnostic is probably ok in my mind. (again, up for discussion)

independentid commented 7 months ago

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.