# WG Meeting: 2024-02-20
## Agenda
- New CAEP Events
- De-coupling SSF from CAEP / RISC
-
## Attendees
- Mike Kiser (SailPoint)
- Atul Tulshibagwale (SGNL)
- Tom Sato (VeriClouds)
- Shayne Miel (Cisco)
- Apoorva Deshpande (Okta)
- George Fletcher (Capital One)
- Nancy Cam Winget (Cisco)
- Ravi Chhetri (VeriClouds)
- Stan Bounev (VeriClouds)
- Jen Schreiber ()
- Tim Cappalli (Okta)
- Sean O'Dell (Disney)

## Notes
### New CAEP Events
- (Apoorva) There's a "session fingerprint" claim. How is it different than the subject of the event
- (Apoorva) The "session presented" event: There seem to be a number of use cases, so how do we define the standard claims within that
- (Apoorva) If you are changing the UA fingerprint, then you are changing the session, so why do you need another fingerprint
- (George) There may be number of pieces of data that can contribute to building confidence about the session. We need not be prescriptive about what goes into the event
- (George) A cross-channel use case is very interesting. If a user uses one channel to authenticate to another channel, does this help correlate those events
- (George) What are we trying to represent by "session"?
- (George) You need some way to represent a machine identity / non-logged in user activity
- (George) You could say the subject is the "session identifier", but you could still send other signals using the "session established" / "session presented" events
- (Shayne) If you are trying to use something to identify the sesion, then those things go into the subject. So the fingerprint is not identifying the session, but presenting some qualities of the session
- (Shayne) This might be worth mentioning in the spec
- (George) It is contextual data about the session, as seen at the Transmitter
- (Shayne) No algorithm is specified for calculating the fingerprint
- (Nancy) There needs to be some semantic on how to calculate and use that value
- (Atul) Probably makes sense as a separate claim, so that you can detect the change
- (Nancy) We may not want to nail down an algorithm, but we should agree on a semantic interpretation
- (Nancy) One more question: IP addresses can rotate or change, so how do we respond to that in this event?
- (Tim) People are still using "source address". People want to know, and while it might be a legacy idea, it might still be useful
- (George) All of these are contextual signals. Some person may have a static IP, and if they ever logged in from another place, it would be anomalous. Similarly other contextual data can be used for such detection. We should have a way for adding other contextual data, e.g.: IP address, protocol in use, etc.
- (Apoorva) Would the contextual data be used in creating the fingerprint
- (Apoorva) Standardizing the claims will help interoperability
- (Apoorva) Should there be two separate events?
- (Atul) Session established means "I see this user for the first time", whereas a session presented means "I see this user return"
- (Shayne) One simple reason for different event types is that there will be a lot of "session presented" events and only a few "session established" event
- (Sean) The "session established" can result in more prescriptive action (e.g. SCIM delete)
- (Sean) Fingerprinting could be a problem for privacy
- (George) Any contextual data will have potential privacy issues. So what do these events mean for consent, policy, etc.
- (Sean) We could have a "PPID" that could have better privacy properties
-

## Action Items