[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