# WG Meeting: 2024-06-18
## Agenda
- Risk score in Session Presented event
- Call schedule
- Blog draft feedback

## Attendees
- Sean O'Dell (Disney)
- Shayne Miel (Cisco)
- Atul Tulshibagwale (SGNL)
- Nick Wooler (Cisco Webex)

## Notes
### Risk Score
- (Sean) A risk indicator could be added to more events
- It's a behavioral indicator, which could apply to a lot of things
- This can map to something Shayne talked about, which is a "risk score changed" event
- You could give the reason within the "Session Presented" event, but not the score itself
- (Atul) I'm a bit concerned about a "confidence score" in general transmitter events
- (Sean) It's not a confidence score
- (Shayne) What is the value of putting it in the session presented event
- (Atul) Risk score is always associated with the session presence
- (Shayne) That's not true - a risk score could change due to other activity, e.g. 3 other people got hacked, so this could also be hacked
- (Shayne) You could send two events: "session presented" and "risk score changed", and tie them with the same `txn` value
- (Sean) Thinking it through from a race condition: If the ITDR system is doing its job, then you should not see a "session presented" event, you should just be OK with a "risk score changed" event
- (Atul) There are two independent vectors here. Unusual activity within an app, and unusual activity across different apps, where each individual app doesn't see anything unusual
- (Sean) Now I think the risk score is needed in both places - "session presented" and "risk score changed"
- (Atul) We could revisit whether to put one event in one SET, and add both those events in one SET
- (Nick) Are there standard risk indicator levels like SAML?
- (Atul) I had proposed 4 levels in the PR
- (Sean) The "session presented" event has an interesting consequence: If I have a Fidelity account linked to the Schwab account, if the Fidelity service calls the Schwab service on behalf of a user, without user presence.
- (Atul) That could be a separate event, because that represents a token compromise rather than the user doing something unusual
- (Shayne)

### Biweekly schedule?
- (Atul) Should we meet biweekly going forward?
- (Shayne and Sean) agree

### Blog draft feedback
- (Shayne) Should we update the draft? It's an important part of the security review
- (Atul) OK by me
- (Shayne) What is the proposed new language?
- (Sean) The last line in the 3rd paragraph of Section 7 does say that right now
- (Atul) 9110 covers bearer authentication in Section 11. The last sentence begins with "This authorization must ...", which references that, therefore we are OK.

## Action Items
- Atul to fix the blog post action and send to Elizabeth
- Atul to ask Mike to change the cadence of the meeting to biweekly, so the next meeting will be on July 2nd.