[Openid-specs-risc] Call notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Feb 20 19:07:22 UTC 2024
Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20240220>.
I realize that the next scheduled meeting is on March 5th, when many of us
will be busy at the Gartner IAM summit. I would like to cancel that one and
meet on March 19th. I have created a notes doc
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20240319> for that meeting with
the agenda item from today that we did not get to.
Atul
--
<https://sgnl.ai>
Atul Tulshibagwale
CTO
<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>
---
WG Meeting: 2024-02-20
<https://hackmd.io/9G0fxp20TPePQqPAUvEjxA?view#Agenda>Agenda
- New CAEP Events
- De-coupling SSF from CAEP / RISC
-
<https://hackmd.io/9G0fxp20TPePQqPAUvEjxA?view#Attendees>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)
<https://hackmd.io/9G0fxp20TPePQqPAUvEjxA?view#Notes>Notes
<https://hackmd.io/9G0fxp20TPePQqPAUvEjxA?view#New-CAEP-Events>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240220/1da0f1a5/attachment-0001.html>
More information about the Openid-specs-risc
mailing list