(Atul) Previously we decided to ignore unkown fields (which is not a recommendation per se). Would prefer a mandated field set rather than a "fill in the blank section.
(Yair) so it's ok to add additional fields, then
(Atul) yes. would rather not add optional fields because of interoperability issues / past history
(Apporva) there may be metadata that extends to all events as well
(Atul) how do you decide on interoperability? if two parties agree to it, that can be between them. what mandates a need?
(Yair) in device compliance, type of device is an example of what might be helpful for the event itself
(Atul) so are you suggesting device type + meta fields?
(Yair) device type may not be the only field that might be helpful. And several of them may be optional . .
(approva) Are we going into raw data sharing then, rather than state change, etc? (syncing)?
(Atul) that's a separate issue (syncing). What Yair is saying is that additional info on a particular event to enhance the decision making... I feel that these events should be dependent on the event that you're talking about; it's too hard to make a generalization about all events (it's too vague)
(Yair) I agree with that - so we're back to device compliance events specfiically. Do we want to make the approach more standard?
(George) It feels like we should identify the use cases that need to be standardized and then work with that. From an enterprise point of view, having that additional info enhnaces the use case without dependency on specfiic vendors /tools.
(Atul) I think that eadch of these events represent some specific use cases ... ie device compliance events might need more info. But George is right with a use case focus
(Yair) a specific use case: you send the subject of the device compliance event, and as part of that you send an identifier that may be dependent on device type. It's super helpful to have device type as part of the event to make sense of the subject in the event
(atul) so it sounds like we should have a discussion (here or elsewhere) that should determine what additional fields that should be added for the device compliance event
(Yair) agreed.
(Atul) Proposed that Yair submit what would be helpful and then we can discuss it in detail.
(gail) checking on any follow up actions from last week . .
(Yair) Because events represent a point of time decision, there is no way to know the current status of the state communicated by the event. We could add a way for the receiver to request the status of an event type. Should we use the same event type? Should we have different event types for this? Does it make sense for all events (e.g. credential change)
(Mike) Is this just a single request?
(Yair) It could be an API that queries for a single subject, but the last time we discussed, people thought of getting this for all subjects too. There could be multiple events associated with a user
(Sean) After a session revoked event, we wanted the status of the user, i.e. was the session revoked? This was a while back, when we discussed how to incorporate streaming. I'm all for it, especially for a single subject
(Apoorva) It makes complete sense. We'd discussed it earlier. One issue was the lack of unified identity. We also thought we needed bulk operations for this. Is this within the charter of SSWG?
(Atul) This could be done like a verification event, but have a status event where when requesting the event, you declare which event types you're looking for, and the response is a status event that gives you the latest status for those.
(Apoorva) We should also think in CRL terms. There's some work going on in terms of OAuth token introspection
(Sean) The context in which I've seen it done, is instead of returning the whole SET. I don't think it's a bad idea to put in the spec, but it should be an optional claim. There is some identity complexity here. It is probably outside of the scope of SSWG
(Mike) The SCIM Events spec should be released shortly, so we could rely on that.
(Sean) SCIM declares a schema for user, but not for device, and other concepts touched upon by CAEP.
(Yair) Adding it here saves implementers to not have to implement one more standard (SCIM Events)
(Sean) This is a way to make this standard more prescriptive than just descriptive.
(Sean) Mike and I are working on a proposal that we will introduce shortly.
(Mike) We will hopefully identify the use case in our proposal.
(Sean) This has always been a blind spot. I could tell an IdP to go do something, but we don't have a way for them to confirm that they've done it.
(Sean) We
(George) This came up on the IPSIE call. Karl wrote a great document about it.
(George) The current feeling is that we can't do prescriptive things with SSF, the more we are clear about how to support this, the better.
(Sean) Is it worthwhile for one of us to attend the IPSIE calls to coordinate on this? (Get requirements from IPSIE into the action receipts proposal.)
(George) Once Mike has something, it'll be great to present that in IPSIE.
(Mike) We could drop in next week to give them a heads up.
(Jen - in comments) It'll be good timing it to present it to IPSIE next week.
(Sean) Who co-chairs?
(George) Aaron and Dick are co-chairs, and Karl is heavily involved.