-
Notifications
You must be signed in to change notification settings - Fork 18
WG Meeting: 2026‐07‐14
Atul Tulshibagwale edited this page Jul 20, 2026
·
1 revision
- Administrative:
- Verification SLA (Issue #339)
- Events base URL continued discussion, (Issue #340)
- Atul Tulshibagwale (CrowdStrike)
- Yair Sarig (Omnissa)
- Sahil Mukhija (CVS Health)
- Thomas Darimont (OIDF)
- Danny Zollner (Okta)
- Mike Kiser (SailPoint)
- Sean O'Dell (CVS Health)
- (Atul) Apple mentioned this issue
- (Jen) Do we have SLAs for anything right now?
- (Yair) It's hard to define SLAs in a certification program. Any SLA we provide needs to be very generous, because you can't account for any fine-grained consideration
- (Sahil) We can specify a timeout?
- (Atul) The proposal was to add a configuration parameter in the stream configuration, but I thought right now we could provide a "hard coded" limit in the certification test
- (Thomas) Currently in the conformance tests we have a de-facto limit. When we run with push delivery, after sending out a verification request, we expect to receive a response event within 60 seconds. For poll delivery, when the receiver request verification. We poll after 5 seconds, and if we don't get the event then we fail the verification test. This is an inconsistency, because there is no specification right now. When we are testing receivers, our transmitter sends out the verification event within 1-2 seconds after receiving a request.
- (Yair) There's a practical limit in real world testing, so it's OK to have a limit within the certification tests. It's not the same as saying anytime anyone requests an event, you must respond in a certain amount of time.
- (Atul) Whether or what you are testing the SLA clock starts. If you are testing a Tx once you send out and receive the verificaiton request...the clocks starts. For Poll delivery means its ready to be delivered and if the Rx does not poll, its up to the Rx. Would like this to come to the streaming config but not there.
- (Atul) To Yair's point putting it in the spec is weird, but putting it in the certification spec is better for testing and validation purposes. Just add it to the certificaiton tests (expecting a response).
- (Sean) agreed on certifcation tests
- (Mike) Problem solved, Thomas made some clarity. Maybe next round you put it in teh stream config
- (Atul) Agreed and repeated what Mike said.
- (Thomas) aligning periods of TTL for Push and Pull - not a problem. Maybe in the issue, in the future, there might be fields to commuinicate expectations on TTL's.
- (Atul) where verifcaiotn is done we should show in the screens, in the conformance test.
- (Atul) This is great so we can continue on without stopping progress. Atul will make that request for the candidate spec with OIDF.
- (Atul) - Plancing on path matters for the SSF spec
- (Thomas) - explaining the Issue about the URI being different from the baseURI in CAEP and RISC specs. Maybe add it as an errata? Once done we have a clear pattern going forward...nothing breaking
- (Yair) if the version is put before the event name and after event-type its inline with the spec. All Event types will have "/secevent/caep/event-type" (i.e. "..../secevent/caep/event-type/v1.1)". The versioning is before the name of the event.
- (Atul) - Similar proposal but different order of name in a path. To Thomas' point so versioning the CAEP spec and versioning the spec the version name should go after the family name. We should have a SSF path in the URI. HOwever, totally against changing it in the current spec. When we introduce event versioning we introduce this when the spec is changed..
- (Thomas) just saying the pattern clear without changing the semantics
- (Atul) if you change the base URI it will be a breaking change
- (Thomas) adding the eventBase URI as an errata not a breaking change.
- (Atul) Logically it makes sense but chaning the spec does NOT make sense. ]
- (Thomas) we are not changing the baseURL, but we are only extracting the paragraph to show it as such. If you go to the stream verification or updated uses the same base path and Thomas just wants to clarify it.
- (Atul) what would we gain from putting in an errata?
- (Thomas) we could integrate the errate into the text
- (Atul) not sure if errata is needed or the baseURI is "wrong" with the spec?
- (Thomas) an errate is not to correct ours but make it clearer.
- (Atul) we actually changed the URI's later and "/ssf" was not in there. It is an omission in the spec but not sure if it should change the spec
- (Thomas) agrees, but would like it to be explicit and use it for a revised 1.1
- (Atul) So where do we put the version indicator event name, type or family name?
- (Sean) after event-type but before event name (i.e. ...secevents/caep/event-type/v2.0/session-revoked)
- (Atul) Show we rev the SSF Spec to specify this or CAEP and RISC?
- (Yair) in his PR he added it into CAEP spec
- (Atul) agreed on CAEP and likely easier than in SSF holistically.
- (Yair) PR for device mgmt needs to be reviewed. (PR #329)
- (Thomas) do you need a new file?
- (Yair) maybe?
- (Atul) The filename does not have the version number until you go through the verification process (like IETF does)
- (Sean) Are we versioning the CAEP spec?
- (Atul) yes
- (Sean) When you version the spec, do we automatically version the URI? It's going to be confusing for implementers
- (Yair) Once you version the spec, you add / change the events you change the URIs for the new / changed events
- (Yair) Imagine we are at version 1.5, some events might be still 1.0, 1.1, 1.2, ... etc. The spec is still self-contained. You list all events in the same spec.
- (Sean) When you get to 1.1, you have to have an EOL plan for 1.0. The operationalization and engineering / productionization aspect needs to be addressed.
- (Yair) These are two different events. 1.1 Device compliance change is different from 1.0 device compliance change. When we go to 1.1, will all receivers need to change to 1.1?
- (Sean) We need to have a plan to EOL 1.0 intentionally when we introduce 1.1
- (Atul) The clock has to be really long on the EOL
- (Sean) Adding to should not break, modifying does break.
(Sean) New Profile for SSF, might overlap with IITP.