Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
iamseanodentity opened this issue Mar 26, 2024 · 3 comments

Comments

@iamseanodentity
Copy link

iamseanodentity commented Mar 26, 2024

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
Copy link
Collaborator

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
Copy link

(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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants